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permission  to  manufacture,  use.  or  sell  any  patented  invention  that  may  in  any  way  be  related 
thereto 


This  report  has  been  reviewed  by  the  Office  of  Public  Affairs  (ASD/PA)  and  is  releasable  to  the 
National  Technical  Information  Service  (NTIS)  At  NTIS.  it  will  be  available  to  the  general 
public,  including  foreign  nations. 
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This  technical  report  discusses  the  System  Design  Specifications  of 
the  I CAM  Integrated  Information  Support  Systea  (IISS).  The  report 
allocates  the  functionality  to  five  CPCI's,  the  network  Transaction 
Manager  (MTM).  the  Coaaon  Data  Model  (CDM).  the  User  Interface  (UI). 
the  Virtual  Terminal  Interface  (VTI)  and  Communications  Subsystems. 
Scenarios  are  presented  to  support  the  identification  of  the 
functional  specifications  of  eaoh  subsystem.  -  j 
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PREFACE 


This  system  design  specification  the  work  perforaed  under 
Air  Force  Contract  F33615-80-C-5155  (ICAM  Project  6201).  This 
contract  is  sponsored  by  the  Materials  Laboratory,  Air  Force 
Systeas  Coaaand.  Wright-Pat terson  Air  Force  Base,  Ohio.  It  was 
adainistered  under  the  technical  direction  of  Mr.  Gerald  C. 
Shuaaker,  ICAM  Prograa  Manager,  Manufacturing  Technology 
Division,  through  Project  Manager,  Mr.  David  Judson.  The  Priae 
Contractor  was  Production  Resources  Consulting  of  the  General 
Electric  Coapany,  Schenectady,  Mew  York,  under  the  direction  of 
Mr.  Alan  Rubens tein.  The  General  Electric  Project  Manager  was 
Mr.  Myron  Hurlbut  of  Industrial  Autonation  Systeas  Departaent, 
Albany.  Hew  York. 

Certain  work  ained  at  iaproving  Test  Bed  Technology  has 
been  perforaed  by  other  contracts  with  Project  6201  perforaing 
integrating  functions.  This  work  consisted  of  enhancements  to 
Test  Bed  software  and  establishment  and  operation  of  Test  Bed 
hardware  and  conauni cat ions  for  developers  and  other  users. 
Documentation  relating  to  the  Test  Bed  fron  all  of  these 
contractors  and  projects  have  been  integrated  under  Project  6201 
for  publication  and  treatment  as  an  integrated  set  of  documents. 
The  particular  contributors  to  each  document  are  noted  on  the 
Report  Documentation  Page  (DD1473).  A  listing  and  description 
of  the  entire  project  docuaentation  systen  and  how  they  are 
related  is  contained  in  document  FTR620100001 ,  Project  Overview. 

The  subcontractors  and  their  contributing  activities  were 
as  follows: 


TASK  4.2 

Subcontractors  Role 

Boeing  Military  Aircraft  Reviewer. 

Coapany  ( BMAC ) 

D.  Appleton  Coapany  Responsible  for  IDEF  support, 

(DACOM)  state-of-the-art  literature 

search . 

General  Dynamics/  Responsible  for  factory  view 

Ft.  Worth  function  and  information 

models . 
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Role 


Subcontractors 

Illinois  Institute  of 
Technology 

Korth  American  Rookwell 
Northrop  Corporation 

Pritsker  and  Associates 
SofTech 

TASKS  4.3  -  4.9  (TEST  BED) 

Subcontractors 

Boeing  Military  Airoraft 
Conpany  (BMAC) 

Computer  Technology 
Associates  (CTA) 

Control  Data  Corporation 
(CDC) 


D.  Appleton  Company 
(DAGOM) 


Responsible  for  factory  view 
funotion  research  (IITRI) 
and  information  models  of 
small  and  medium- size  business. 


Responsible  for  fafetory  view 
function  and  information 
models. 

Responsible  for  IDEF2  support. 
Responsible  for  IDEFO  support. 


Responsible  for  consultation  on 
applications  of  the  technology 
and  on  IBM  oomputer  technology. 

Assisted  in  the  areas  of 
communications  systems,  system 
design  and  integration 
methodology,  and  design  of  the 
Network  Transaction  Manager. 

Responsible  for  the  Common  Data 
Model  (CDM)  implementation  and 
part  of  the  CDM  design  (shared 
with  DACOM). 

Responsible  for  the  overall  CDM 
Subsystem  design  integration 
and  test  plan,  as  well  as  part 
of  the  design  of  the  CDM 
(shared  with  CDC).  DACOM  also 
developed  the  Integration 
Methodology  and  did  the  schema 
mappings  for  the  Application 
Subsystems. 


Reviewer. 


Role 
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Subcontractors 

Digital  Equipment 
Corporation  (DEC) 


McDonnell  Douglas 
Automation  Company 
(McAuto) 


On-Line  Software 
International  (OSI) 


Role 

Consulting  and  support  of  the 
performance  testing  and  on  DEC 
software  and  computer  systems 
operation. 

Responsible  for  the  support  and 
enhancements  to  the  Network 
Transaction  Manager  Subsystem 
during  1984/1985  period. 

Responsible  for  programming  the 
Communications  Subsystem  on  the 
IBM  and  for  consulting  on  the 
IBM. 


Rath  and  Strong  Systems 
Products  (RSSP)  (In  1985 
became  McCormack  9  Dodge) 


SofTech ,  Inc . 


Software  Performance 
Engineering  (SPE) 


Structural  Dynamics 
Research  Corporation 
(SDRC) 


Responsible  for  assistance  in 
the  implementation  and  use  of 
the  MRP  II  package  (PIOS)  that 
they  supplied. 

Responsible  for  the  design  and 
implementation  of  the  Network 
Transaction  Manager  (NTM)  in 
1981/1984  period. 

Responsible  for  directing  the 
work  on  performance  evaluation 
and  analysis. 

Responsible  for  the  User 
Interface  and  Virtual  Terminal 
Interface  Subsystems. 


Other  prime  contractors  under  other  projects  who  have 
contributed  to  Test  Bed  Technology,  their  contributing 
activities  and  responsible  projects  are  as  follows: 


Contractors 

ICAK  Project 

Contributing  Activities 

Boeing  Military 
Aircraft  Company 
( BMAC) 

1701 .  2201 . 
2202 

Enhancements  for  IBM 
node  use.  Technology 
Transfer  to  Integrated 
Sheet  Metal  Center 
( I SMC ) . 

SDS620 140000 
1  November  1985 


Contractors 

ICAM  Project 

Contributing  Activities 

Control  Data 
Corporation  (CDC) 

1502,  1701 

IISS  enhancements  to 
Common  Data  Model 
Processor  (CDMP). 

D.  Appleton  Company 
(DAOOM) 

1502 

IISS  enhancements  to 
Integration  Methodology. 

General  Electric 

1502 

Operation  of  the  Test 
Bed  and  communications 
equipment . 

Hughes  Aircraft 

Company  (HAC) 

1701 

Test  Bed  enhancements. 

Structural  Dynamics 
Research  Corporation 
(SDRC) 

1502.  1701. 
1703 

IISS  enhancements  to 
User  Inter face/ Virtual 
Terminal  Interface 
(UI/VTI). 

Systran 

1502 

Test  Bed  enhancements. 
Operation  of  Test  Bed. 

MOTE 

Revision  A  of  this  System  Design  Specification  has  been 
made  at  the  end  of  the  project  to  update  the  document  to  reflect 
what  was  actually  accomplished,  or  the  “As  Built“  design.  The 
initial  design  to  reflected  the  best  thinking  as  to  what  was 
desirable  and  believed  to  be  possible  at  the  time  it  was 
designed.  In  most  cases  the  design  has  been  carried  out,  but  in 
some  cases  the  full  capability  has  not  yet  been  provided.  Such 
cases  have  been  marked  as  “(Future)”  in  this  revision  so  as  not 
to  lose  the  thinking  that  went  into  this  design  and  to  also  be 
accurate  as  to  what  is  actually  implemented. 

In  other  cases,  the  design  or  equipment  conf iguration 
indicated  was  initially  implemented  but  then  changed  as  the 
project  progressed.  Where  important,  or  possibly  misleading, 
these  "Initial  Implementation"  capabilities  are  also  indicated. 

In  this  revision  there  were  minor  revisions  made  to  all 
sections  except  that  of  the  User  Interface  (Section  3.1.3), 
which  was  revised  extensively  to  reflect  the  actual 
implementation  of  the  User  Interface  which  haul  considerably  more 
capability  than  the  original  design,  and  which  had  changed  some 
architecturely  from  the  concepts  originally  presented. 


vi 


SDS620 140000 
1  November  1985 


TABLE  OF  CONTENTS 


Page 


SECTION  1.0  SCOPE  .  1-1 

1.1  Ideal ificaii on  .  1-1 

1.2  Functional  Summary  .  1-1 

SECTION  2.0  REFERENCES  .  2-1 

2.1  Applicable  Documents  .  2-1 

2.2  Terms  9  Abbreviations  .  2-2 

2.3  System  Overview  . 2-5 

2.3.1  Background  . 2-5 

2. 3. 1.1  Relationship  of  the  Test  Bed 

to  Other  I  CAN  Projects  .  2-6 

2. 3. 1.2  Strategy  for  Evolution  .  2-7 

2.3.2  Summary  of  Expected  Benefits 

of  the  Test  Bed  and  IISS  .  2-9 

2.3.3  Test  Bed  System  Overview  .  2-11 

2.3.3. 1  Hardware  Architecture  .  2-11 

2. 3. 3. 2  Software  Architecture  .  2-14 

SECTION  3.0  REQUIREMENTS  .  3-1 

3.1  System  Definition  .  3-1 

3.1.1  Network  Transaction  Manager 

Configuration  Item  .  3-1 

3 . 1 . 1 . 1  Network  Transaction  Manager 

Mission  Statement  .  3-1 

3. 1.1. 2  Network  Transaction  Manager 

Functional  Areas  .  3-1 

3. 1.1. 3  Network  Transaction  Manager  \ 

Operational  Scenario  .  3-3  | 

3. 1.1. 4  Network  Transaction  Manager 

Functional  Specifications  .  3-35  ! 

3.1.2  Common  Data  Model  Configuration 

Item  .  3-54 

3. 1.2.1  CDM  Mission  Statement  .  3-54 

3. 1.2. 2  CDM  Functional  Areas  .  3-54 

3.1.3  The  User  Interface 

Configuration  Itei  .  3-82 

3. 1.3.1  User  Interface  Mission  ; 

Statement  .  3-82  ! 

3. 1.3. 2  User  Interface  Functional  * 

Areas  .  3-83 

3. 1.3. 3  User  Interface  Operational  | 

Scenarios  .  3-85  1 


vi  i 


J 


SDS620 140000 
1  November  1985 


TABLE  OF  CONTENTS  (Continued) 


3.1 .3.4 

3.1.4 

3. 1.4.1 

3. 1.4. 2 

3. 1.4. 3 


3. 1.4. 4 


3.1.5 


3.1 .5.1 

3. 1.5. 2 


3. 1.5.3 


3. 1.5. 4 


3.2 

3.2.1 

3.2.2 

3.2.2. 1 

3. 2. 2. 2 

3. 2. 2. 3 

3. 2. 2. 4 

3. 2. 2. 5 


3. 2. 2. 6 

3. 2. 2. 7 

3. 2. 2. 8 

3. 2. 2. 9 

3.2.2.10 

3.2.2.11 

3.2.2.12 
3.2.3 

3.2.3. 1 

3.2. 3.2 

3. 2. 3. 3 


Page 


Functional  Specifications  .  3-95 

The  Virtual  Terminal  Interface 

Configuration  Item .  3-110 

Virtual  Terminal  Mission 

Statement  .  3-110 

Virtual  Terminal  Functional 

Areas  .  3-111 

Virtual  Terminal  Operational 

Scenarios  .  3-111 

Virtual  Terminal  Functional 

Specifications  .  3-116 

The  Communication  Subsystem 

Configuration  Item .  3-118 

Communication  Subsystem  Mission 

Statement  .  3-118 

Communication  Subsystem 

Functional  Areas  .  3-119 

Communication  Subsystem 

Operational  Scenarios  .  3-119 

Communication  Subsystem 

Functional  Specifications  .  3-136 

Interfaces  .  3-139 

Information  Interfaces  .  3-140 

Services  Provided  .  3-141 

Integrated  Application  Programs..  3-141 
Mon-Integrated  Application 

Processes  .  3-141 

Comuon  Data  Model  .  3-141 

Distributed  Database  Processes  . .  3-143 
Local  Database  Management 

Systems  .  3-143 

Network  Transaction  Manager  .  3-143 

User  Interface  .  3-149 

Communications  .  3-149 

Test  Bed  Monitor  .  3-150 

Interprocess  Communications  .  3-150 

Virtual  Terminal  Interface  .  3-150 

Host  Operating  Systems  .  3-151 

Protocols  and  Messages  .  3-151 

AP  to  AP  .  3-151 

AP  to  CDM  .  3-152 

AP  to  NTM  .  3-152 


vi  i  i 


4 


SDS620 1 40000 
1  November  1985 


TABLE  OF  CONTENTS  (Continued) 


3. 2. 3. 4  AP  to  DI  .  3-152 

3. 2. 3. 5  CDM  to  CDM  .  3-152 

3. 2. 3. 6  NTM  to  NTH  .  3-152 

SECTION  4.0  QUALITY  ASSURANCE  PROVISIONS  .  4-1 

4.1  General  4-1 

4.1.1  Responsibility  for  Test  .  4-1 

4.2  Special  Tests  and  Examinations  .  4-1 

SECTION  5.0  PREPARATION  FOR  DELIVERY  .  5-1 

5.1  Hardware  5-1 

5.2  Software  5-1 

5.3  Documentation  .  5-1 

5.3.1  NTM  Programmer's  Manual  .  5-1 

5.3.2  NTM  Operator's  Manual  .  5-1 

5.3.3  Common  Data  Model  Administrator's 

Manual  .  5-2 

5.3.4  Precompiler  User's  Guide  .  5-2 

5.3.5  NDML  User's  Manual  .  5-2 

5.3.6  UIMS  User's  Manual  .  5-2 

5.3.7  VTI  Programmer's  Manual  .  5-3 

5.3.8  Forms  Processor  Application 

Programmer  Manual  .  5-3 

5.3.9  Interim  Forms  Editor  Manual  .  5-3 

5.3.10  NDDL  User's  Guide  .  5-3 

LIST  OF  ILLUSTRATIONS 

Figure  Title  Page 

2- 1  Interconnection  of  Heterogeneous 

Systems  via  Local  Area  Network  .  2-12 

3- 1  NTM  Configuration  Tree  .  3-2 

3-2  Cluster  APs  .  3-5 

3-3  Ease  in  Implementation  .  3-6 

3-4  Host  1  .  3-7 

3-5  IISS  Architecture  -  Conceptual  Model  .  3-8 

3-6  NTM  Environment  on  One  AP  Cluster  .  3-9 

3-7  NTM  Environment  on  UI  WS  .  3-10 

3-8  NTM  Environment  on  COMM  WS  .  3-11 


SDS620 1 40000 
1  November  1985 


LIST  OF  ILLOSTRATIOHS  (Continued) 

Page 

3-9  Operate  Network  Transaction 

Manager  Functions  .  3-15 

3-10  Manage  Messages  Functions  .  3-16 

3-11  Manage  Processes  Functions  .  3-17 

3-12  Maintain  Operability  Functions  .  3-18 

3-13  CoMsunicate  with  Application  Process  .  3-19 

3-14  NTM  Architecture  Test  Bed  Overview  .  3-21 

3-15  Spawning  Scheduler  .  3-25 

3-16  Message  Authentication  .  3-29 

3-17  NTM  IDEF1  Concepts  .  3-31 

3-18  NTM  IDEF1  Concepts  .  3-32 

3-19  End-to-End  Addressing  .  3-33 

3-20  Guaranteed  Delivery  .  3-37 

3-21  CDM  -  Configuration  Tree  .  3-56 

3-22  A-0  Develop  Integrated  Application 

Processes  .  3-58 

3-23  A-0  Operate  CDM  .  3-59 

3-24  AO  -  Operate  CDM  Functions  .  3-60 

3-25  A1  -  Maintain  CDM  Data  Functions  .  3-61 

3-26  Develop  Integrated  Application 

Processes  .  3-66 

3-27  Precompile  Application  Process  .  3-69 

3-28  NDML  Precompiler  Environment  .  3-70 

3-29  Distributed  Query 

Scheduling  0  Control  .  3-75 

3-30  User  Interface  Configuration 

Tree  .  3-84 

3-31  User  Interface  Management  System  .  3-85 

3-32  Display/Retrieve  a  Form  .  3-88 

3-33  Filling  Out  a  Form  -  User 

Viewpoint  .  3-89 

3-34  Control  Diagram  -  Form  Processor  .  3-90 

3-35  Form  Processor  Start  Up  .  3-92 

3-36  User  Log  On  Scenario  .  3-93 

3-37  Application  Generation  .  3-95 

3-38  VTI  Configuration  Tree  .  3-112 

3-39  Interface  to  a  Real  Terminal  .  3-113 

3-40  Data  Acquisition,  Conversion, 

Transmission  .  3-114 

3-41  Interface  to  an  Existing 

Application  Program  .  3-116 


SDS620 140000 
1  November  1985 


LIST  OF  ILLPSTRAT101IS  (Continued) 


Page 


3-42  Communication  Subsystem: 

Configuration  Tree  .  3-120 

3-43  Test  Bed  Local  9  Wide  Area  Network 

Configuration  .  3-122 

3-44  Genet  Permanent  Virtual  Circuit  .  3-123 

3-45  Writing  9  Reading  into 

Mail  Box  .  3-127 

3-46  Interhost  Communication  9  Overview  .  3-134 

3-47  Message  Scheduling  (Interhost)  .  3-131 

3-48  Line  Protocol  Transmission  .  3-133 

3-49  IISS  Test  Bed  System  Overview  .  3-142 

3-50  IISS  Test  Bed  Software  Information 

Interfaces  .  3-144 

3-51  Structure  of  a  Typical  IISS 

Application  Process  .  3-145 

3-52  Predefined  Query  Processing  .  3-146 

3-53  Exaaple  Protocols  Between  IISS 

Te&t  Bed  Processes  .  3-153 


xi 


SDS620 140000 
1  Hovember  1985 


SECTION  1 
SCOPE 


1 . 1  Identification. 


This  specification  establishes  the  conceptual  design  of  the 
system  identified  as  the  Integrated  Information  Support  System 
(IISS)  otherwise  referenced  as  the  I CAM  Test  Bed.  This  system 
is  intended  to  be  a  computing  environment  that  provides 
integrated  data  management  facilities  and  distributed  processing 
for  heterogeneous  databases  resident  on  heterogeneous  computer 
systems  interconnected  via  a  Local  Area  Metwork.  This  computing 
environment  is  to  be  used  for  demonstrating  the  integration  of 
the  data  produced  by  three  distinct  manufacturing  subsystems: 
Shop  Floor  Management  (MCMM) ,  Decision  Support  (IDSS)  and 
Material  Requirement  Planning  (MRP). 

This  document  has  been  prepared  by  Project  Priority  6201M 
of  the  Air  Foroe's  I CAM  program.  This  project  is  conducted  by 
the  General  Electric  Company,  with  the  participation  of  other 
contractors  as  presented  in  the  Preface  of  this  document  and 
.supported  by  various  consultants  and  contributors. 

This  project  is  sponsored  by  the  Manufacturing  Technology 
Division  of  the  Air  Force  Wright  Aeronautical  Laboratories. 

1 .2  Functional  Summary 

The  Integrated  Information  Support  System  (IISS)  is  a  test 
computing  environment  used  to  investigate  and  demonstrate  and 
test  the  concepts  of  information  management  and  information 
integration  in  the  contexts  of  Aerospace  Manufacturing. 
Specifically,  IISS  addresses  the  problems  of  integration  of  data 
resident  on  heterogeneous  databases  supported  by  heterogeneous 
computers,  interconnected  via  a  Local  Area  Metwork.  A  Common 


•Four  data  classes  are  defined  as  follows: 

Class  I  -  data  totally  managed  by  CBIS 

Class  II  -  data  directly  accessed  by  CBIS,  but  externally 

managed 

Class  III  -  data  subject  to  CBIS  standards  and  procedures 
Class  IV  -  data  subject  to  CBIS  guidelines 

A  fifth  class,  defined  as  "private  data,”  is  totally  outside  of 
the  control  of  the  CBIS  policies  and  procedures. 
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Data  Model  is  maintained  and  provides  the  mechanism  required  to 
integrate  the  data.  Initial  data  integration  is  targeting  the 
Class  II  environment;  however,  IISS  is  required  to  be  extensible 
to  the  Class  I  data  environment.  The  definitions  of  the  Class  I 
and  Class  II  data  environments  appear  in  Section  2.2. 
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2.2  Terms  and  Abbreviations 

Active:  Computer -enforced  (at  oompile  tiae  or  at  run  time). 

Activity  Framing:  Feature  which  allows  to  declare  a  set  of 
Application  Processes  as  being  part  of  a  single  operation  which 
aakes  sense  froa  the  user  viewpoint.  All  database  changes 
contained  within  an  activity  fraae  are  incorporated  or  else  none 
are  incorporated  in  the  databases. 

Appl lcation  Process:  A  cohesive  unit  of  software  that  can  be 
initiated  as  a  unit  to  perfora  soae  function  or  functions. 

Appl lcation  Process  Cluster:  The  logioal  grouping  of 
Application  Processes  and  of  one  Message  Processing  Unit  (MPU) 
NTH  component. 

Application  Subsystem:  An  Application  Subsystem  consists  of  one 
or  aore  application  processes  and  performs  speoific 
a&nufacturing  management  functions.  Instances  of  I CAM 
Application  Subsystems  are:  MC-MM ,  XDSS.  a  commercially 
available  MRP  System. 

Class  II  Data:  Data  for  which  query  activity  is  under  direct 
control  of  the  IISS  and  for  which  update  activity  is  under 
indirect  control  of  the  IISS. 

Common  Data: 

1.  Data  used  by  more  than  one  Application  Subsystem. 

2.  Data  updated  by  one  Application  Subsystem  and  used  by 
another . 

3 .  Data  planned  to  evolve  into  a  category  described  by  (1) 
or  (2)  above. 

Common  Data  Model :  Describes  common  data  application  process 
formats,  screen  definitions,  etc.  of  the  IISS  and  includes 
conceptual  schema,  external  schemas,  internal  schemas,  and 
schema  transformation  operators. 

Data  Integrity :  Improved  quality,  consistency  and 
recoverability.  The  Test  Bed  common  data  is  subject  to  the 
following  integrity  checks: 

1.  Type  checking 
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2.  Existence  ohecking 

3.  Edit  checking  (7-digit  telephone  nuaber) 

4.  Attribute  value  cheeking  (shirtsise  -  snail,  medium, 
large) 

Deadlock:  Two  processes  are  said  to  be  dead  looked  when  each 
process  is  waiting  on  the  other  to  ooaplete  before  proceeding. 

Domain  Check :  Operation  which  ensures  that  the  values  of  a 
given  attribute  lie  within  soee  prescribed  set  of  values.  These 
values  nay  be  continuous,  discrete,  nuaeric  or  non-nuaeric. 

Expert /Mov ice  Mode:  The  User  Interface  supports  the  concept  of 
Expert/Movioe  node  of  user  interaction.  In  the  novice  aode,  the 
user  receives  tutorial  assistance  froa  the  systen  to  guide  his 
selection  of  system  features  and  functions.  In  the  expert  aode. 
the  tine-consuaing  tutorial  assistance  is  suppressed  for  aaxiaua 
efficiency. 

Fora:  Predefined  screen  format  description.  The  description 
includes  the  Textual,  cursor  positioning,  data-checking 
information  required  to  display  or  input  data  into  IISS. 

Guaranteed  Delivery:  Test  Bed  provided  service  which  ensures 
the  delivery  of  a  message  to  its  destination  even  if  the 
destination  process  is  unavailable  at  the  time  the  message  is 
issued. 

Integrated  (Test  Bed)  Appl i cat  ion  Process :  An  Application 
Process  which: 

1.  Uses  the  Neutral  Data  Manipulation  Language  to  retrieve 
Class  II  data  which  may  be  distributed  on  several 
databases  resident  on  the  Test  Bed. 

2.  By  the  end  of  the  contract,  it  uses  the  local  database 
manipulation  language  to  update  the  local  database  to 
which  it  is  bound. 

3.  Performs  its  terminal  input /output  operations  on  the 
Test  Bed  terminals. 

4.  Is  controlled  from  the  Test  Bed  terminals. 
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Won- Integrated  (Test  Bed)  Appl 1 oat Ion  Process :  An  Application 
Process  which: 

1.  Does  not  use  the  Beutral  Data  Manipulation  Language  to 
retrieve  Class  II  data.  The  Local  database  Management 
System  data  manipulation  language  is  used  for  local 
database  manipulation  (update,  retrieval). 

2.  Performs  its  terminal  Input /Output  operations  on  the 
Test  Bed  terminals. 

3.  Is  controlled  from  the  Test  Bed  terminals. 

Mon  Procedural  Query:  Value  stated  query.  The  query  statement 
focuses  on  what  needs  to  be  retrieved  rather  than  on  how  to 
carry  out  the  retrieval  operations. 

Paired  Message:  A  message  which  contains  either  a: 

a.  Request  for  a  reply,  or 

b.  Reply  to  a  uniquely  identified  request. 

Pre -defined  Query  Application  Processes :  Information  processing 
functions  implementing  predefined  data  query  application 
processes.  The  code  required  for  implementation  is  predefined 
(manually  if  necessary)  precompiled  and  linked. 

Response  Time:  Duration  of  wall  clock  time  between  submission 
of  a  user  request  and  receipt  of  the  first  character  of  output. 

Synchronization  Point :  Quiet  point  where  the  following  is  true: 

1.  The  Test  Bed  databases  are  in  a  consistent  state 

2.  The  state  of  the  queues  of  pending  application  process 
is  known  and  available  for  future  reference 

3.  The  state  of  the  databases  is  known  and  available  for 
future  reference 

4.  The  state  of  the  queues  of  pending  application  process 
and  the  state  of  the  databases  have  been  given  a  common 
identifier . 

System  Clean  Point :  State  of  the  system  which  satisfies  to: 
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1.  The  test  bed  databases  are  in  a  consistent  state 

2.  The  state  of  the  databases  is  known  and  available 

S.  The  state  of  the  queues  of  pending  messages  is  known 

and  available. 

S vs ten  Quiet  Point :  Period  of  tine  during  which  the  following 
is  true: 

1.  The  dispatch  of  messages  triggering  the  execution  of 
application  processes  is  suspended. 

2.  All  dispatched  application  processes  are  closed 
(processing  is  completed). 

3.  System  quiet  points  are  invoked  and  terminated  under 
control  of  the  Test  Bed  operator  or  Test  Bed  oontrol 
mechanism. 

Terminal  Control  Words :  A  neutral  representation  of  terminal 
features  Implemented  by  specific  control  characters. 

Test  Bed  Oti 1 ities :  Test  Bed  functions  that  either  provide  Test 
Bed  operability  or  facilitate  the  execution  and  terminal 
input/output  operations  of  the  Application  Processes  resident  on 
the  Test  Bed. 

Time  to  Complete:  Duration  of  wall  dock  time  between 
submission  and  completion  of  a  user  request. 

User  Interface:  Test  Bed  services  which  facilitate  the  man 
machine  dialogs  between  the  Test  Bed  services,  some  of  the 
Integrated  or  Mon-Integrated  Application  Process  resident  on  the 
Test  Bed  and  the  Test  Bed  user.  The  User  Interface  services  are 
available  through  the  Test  Bed  terminals. 

2 . 3  System  Overview 

2.3.1  Background 

The  objective  of  this  project  is  to  establish  and  operate  a 
Test  Bed  to  validate  the  concept  of  Integrated  Applications 
supported  by  an  Integrated  Information  Support  System  (IISS). 

In  addition,  the  project  is  to  establish  a  set  of  interim 
standards  and  procedures  to  guide  the  design  of  the  IISS  and  to 
provide  guidance  to  other  ICAM  projects.  Finally,  a  set  of 
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requirements  is  to  be  established  which  will  be  the  basis  for 
enhancements  to  the  IISS. 

This  project  is  intended  to  provide  the  test  and 
demonstration  vehicle  for  the  I CAM  Information  Support  System 
concepts  described  in  the  30  September  1981  "Integrated  Sheet 
Metal  Center"  (Threads  Dooument)  and  the  Project  Priority  "3101 
Computer  Based  Information  System  (CBIS)  Requirements  Document." 
As  the  strategy  for  evolution  to  the  "CBIS  data  Class  II"  and 
"CBIS  data  Class  I"  (see  footnote  on  Page  1-1  for  a  definition 
of  the  data  classes)  environments  is  developed  and  implemented, 
the  associated  costs  and  benefits  can  be  tracked  against  the 
baseline  system. 

The  I CAM  products  being  considered  by  the  Project  Priority 
2201/2  contractors  for  implementation  in  the  Integrated  Sheet 
Metal  Center  (ISMC)  can  be  implemented  first  on  the  Test  Bed. 

In  this  process,  the  problems  of  rehosting  the  software, 
integrating  multiple  ICAM  products,  and  demonstrating 
performance  will  be  identified  and  solved,  thus  reducing  the 
risk  to  the  ISMC  implementator.  Cost  and  performance 
evaluations  of  the  products  can  be  done  within  the  Test  Bed. 

ICAM  products  not  chosen  for  implementation  in  the  ISMC  can 
also  be  installed  on  the  Test  Bed,  providing  the  same  evaluation 
benefits  and  reduction  of  risk  to  other  potential  users. 

2. 3. 1.1  Relationship  of  the  Test  Bed  to  Other  ICAM  Projects 

The  first  Test  Bed  demonstration  is  to  include  the  shop 
floor  control  system  from  Project  Priority  6103  (Manufacturing 
Control  Material  Management  -  MCMM) ,  integrated  with  appropriate 
modules  of  a  commercially  available  Manufacturing  Resource 
Planning  (MRP)  system.  This  integration  will  be  supported  by 
appropriate  tools  from  the  Integrated  Decision  Support  System 
(IDSS),  similar  in  capability  to  the  "mid-configuration" 
described  in  the  ICAM  Program  Office's  30  September  1981  ISMC 
"Threads  Document . " 

The  oontents  of  the  subsequent  demonstrations  will  depend 
on  several  factors  and  come  from  several  sources.  For  example, 
they  could  come  from  requirements 'recommendations  from  within 
this  Test  Bed  project,  from  the  ICAM  Program  Office,  from  other 
ICAM  Projects  (particularly  ISMC  Projects  2201/2),  and  from 
industry  in  general.  Enhanced  capabilities  in  the  manufacturing 
systems  applications  area  (technical  and  control  threads)  will 
come  mainly  from  projects  5501  (IPS)  and  the  Integrated  Decision 
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Support  Systems  (IDSS)  projects  8203  and  8205.  System 
Engineering  Methodology  (SEM)  tools  will  coae  froa  SEM  Project 
1701 . 


The  Test  Bed  project  has  worked  and  will  continue  to  work 
closely  with  other  related  ICAM  projects  in  deteraining  systea 
requirements,  defining  standards  and  procedures  for  the  initial 
iapleaentation,  and  identifying  deficiencies  and  voids  in  the 
available  coaponents.  Beyond  the  functional  and  application 
areas,  aethods  to  be  used  in  all  aspects  of  the  systea  life 
cycle  are  also  to  be  addressed.  Aspects  to  be  coordinated  with 
the  SEM  (System  Engineering  Methodology  -  ICAM  Project  Priority 
1701)  includes:  data  definition  methods:  database  design;  use 
of  the  data  dictionary;  structured  analysis  aethods;  systea 
specification  techniques;  prototype  development;  standards  for 
data  definition;  data  manipulation;  message  definition;  and 
documentation  standards  and  performance  analysis  techniques. 

Heeds  and  priorities  for  enhancements  will  be  defined  by 
the  ICAM  Program  Office  based  on  recommendations  from  the  Test 
Bed  project  coalition  and  related  projects.  Requirements  for 
the  enhancements  will  be  defined  by  this  Project  (6201). 

Project  Priority  1701M  (SEM)  will  have  the  responsibility  for 
designing  and  building  the  required  software  and  defining  the 
required  standards,  procedures,  and  guidelines  based  on  the 
requirements.  To  facilitate  the  coordination  of  this  Project 
6201  with  Project  1701,  an  informal  working  arrangement  has  been 
established  with  the  Project  1701  Prime  Contractor. 

2. 3. 1.2  Strategy  for  Evolution 

It  has  been  estimated  that  in  large  U.S.  corporations,  most 
of  the  existing  computer  applications  will  be  redesigned  over 
the  next  10  to  20  years.  It  is  further  expected  that,  due  to 
the  rapidly  changing  computer  technology,  the  construction 
techniques  and  operation  modes  of  new  applications  will  bear 
little  resemblence  to  those  of  existing  systems. 

The  Project  Priority  3101  CBIS  coalition  provided  a  set  of 
six  principles  as  guides  in  formulating  a  solution  for  the 
(relatively)  near  term  which  are  also  extensible  for  the 
expected  longterm  trends.  Individually,  each  of  these 
principles  reflects  state-of-the-art  technology;  however,  they 
have  not  been  implemented  together  to  yield  an  integrated 
system.  These  principles  are  stated  as  follows: 

1.  IISS  is  a  key  mechanism  for  the  integration  of 
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computerized  manufacturing .  It  defines,  controls,  and 
executes  actions  affecting  information  among  various 
functionally  independent  subsystems,  based  on  the  use 
of  oommon  data. 

2.  IISS  employs  a  coordinated  database  approach  to  support 
information  resource  management  of  various  application 
systems  in  a  closed  loop  environment  within 

manuf ac tur i ng . 

3.  IISS  implementation  strategy  employs  several  stages  of 
data  and  application  control  which  allow  for  increased 
usage  of  facilities  as  management  seeks  to  gain  greater 
benefits  from  the  IISS. 

4.  IISS  operates  as  a  transaction  oriented  system 
responding  interactively  to  user  commands,  rather  than 
to  prescheduled  batches  of  oomputer  programs. 

5.  IISS  is  accessible  from  geographically  dispersed 
locations . 

These  principles  and  other  results  of  the  CBIS  project  were 
inputs  to  establish  a  starting  point,  extended  and  were  further 
articulated  by  the  ICAM  Program  Office  and  the  Project  6201 
coalition.  Requirements,  specifications,  and  the  overall  system 
design  are  being  developed  with  a  view  of  both  short  and 
long-term  implementation  plans  for  the  Test  Bed.  To  help  focus 
attention  on  the  long-range  needs  of  the  test  bed,  projections 
on  the  future  direction  of  computer  systems  architecture,  and 
the  manufacturing  environment  to  the  year  1990  and  beyond,  and 
the  impact  this  will  have  on  the  Test  Bed  technology,  have  been 
developed.  This  is  published  as  the  "Test  Bed  Migration  Path"  in 
Appendix  C  of  the  System  Requirements  Document  ( SRD620 140000 ) . 

The  "cost  drivers"  which  the  ICAM  CBIS  Requirements 
Definition  (Project  Priority  3101)  defined  as  critically 
associated  with  the  CBIS  environment  are  summarized  in  the 
following  nine  categories,  all  of  which  are  being  considered  as 
part  of  the  Test  Bed  IISS  design: 

1.  Data  independence  -  making  computer  data  files 
independent  of  the  programs  which  use  them. 

2.  Data  nonredundancy  -  minimizing  the  number  of 
occurrences  of  the  same  data  in  different  files. 
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3.  Data  relatability  -  facilitating  the  changing  of  file 
structure  based  on  specific  "views”  required  by 
different  progress  and  transactions . 

4.  Data  integrity  -  isproving  data  quality,  consistency, 
and  recoverability. 

5.  Data  accessibility  -  providing  low-cost,  user-friendly 
access  to  data  stored  in  various  files  and  computers. 

6.  Data  shareability  -  ensuring  that  many  programs  can 
access  the  same  files  simultaneously  without  degrading 
performance . 

7.  Data  security  -  ensuring  that  data  are  isolated  from 
users  who  should  not  have  access  to  it. 

8.  Data  performance  -  providing  proper  controls  for 
chang i ng  the  CBIS  environment  over  time  as  changing 
user  needs  cause  the  basic  system  requirements  to 
change. 

9.  Data  administration  -  supplying  appropriate  standards, 
procedures,  and  guidelines  to  ensure  consistent 
evolution  of  the  CBIS  environment  as  demands  and 
technologies  change. 

Implied  above  is  the  need  for  the  IISS  to  operate  in  a 
mixed  environment  containing  old  and  newly  developed 
applications.  It  is  clearly  recognised  that  the  existing 
applications  must  be  supported,  while  techniques  for  technology 
development  and  new  applications  development  are  concurrently 
provided . 

2.3.2  Summary  of  Expected  Benefits  of  the  Test  Bed  and  IISS 

The  Test  Bed  will  serve  as  a  step  toward  realizing  the  full 
benefits  of  a  CBIS  as  represented  by  the  "cost  drivers"  in  the 
preceding  section  (Section  2. 3. 1.2).  It  will  also  serve  as  a 
facility  to  assist  others  to  achieve  these  benefits  faster  and 
with  less  risk.  Some  of  the  benefits  of  the  Test  Bed  may  be 
summarised  as  follows: 

1.  Provide  testing  facility  for  individual  ICAM  software 
products . 


2.  Demonstrate  initial  integration  of  ICAM  products. 
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•  Data  integration  via  the  Common  Data  Model 

•  Techniques  and  procedures  for  more  extensive 
integration  of  program  functions 

3.  Provide  a  site  for  demonstration  and  evaluation  of  ICAM 
products . 

•  Applications 

•  Methodologies 

•  Information  support  system 

4.  Reduce  risk  to  subsequent  users  of  ICAM  products. 

5.  Provide  standards,  guidelines,  and  procedures. 

•  For  development  of  ICAM  products 

•  For  evaluation/adoption  by  industry 

6.  Demonstrate  strategy  for  transition  from  current 
application  processing  and  development  methods  to  use 
of  the  evolving  techniques  which  will  subsequently 
reduce  cost  and  increase  system  flexibility. 

•  Distributed  heterogeneous  systems,  distributed  data, 
and  distributed  processing. 

•  Independence  of  application  data  from  considerations 
of  actual  internal  storage  organization  and  database 
Management  System  access  techniques. 

•  Reduced  data  redundancy. 

•  Automated  data  validation  and  constraint  checking 
through  the  Common  Data  Model . 

•  Transaction-oriented  applications. 

•  Standardized  user  interface  (similar  menu 
construction  for  all  applications,  standard  user 
"HELP"  procedures,  standard  error  messages,  etc.). 

•  Control  of  execution,  in  a  consistent  manner,  of 
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processes  on  different  computers  using  different 
operating  systems. 

•  Facilitation  and  control  of  the  passing  of  data  and 
messages  between  processes  on  the  same  or  different 
computers . 

•  Consistent  error  handling  throughout  the  system. 

e  System-wide  oontrol  of  startup,  shutdown,  restart, 
and  recovery. 

•  Application  programs  written  using  relational 
database  languages  referencing  nonrelational 
databases . 

•  Independence  of  application  program  from  the 
computer  on  which  the  user  terminal  is  located. 

•  Independence  of  application  program  from  the 
characteristics  of  the  terminal  on  which  it  will  be 
used. 

•  System-supported  translation  of  information  formats 
to  host-specific  representations. 

2.3.3  Test  Bed  System  Overview 

The  following  is  an  overview  of  the  presently  envisioned 
Hardware  and  Software  Architecture. 

2.3.3. 1  Hardware  Architecture 

The  hardware  architecture  of  the  Test  Bed  supports  the 
interconnection  of  the  heterogeneous  computer  systems  required 
to  demonstrate  the  functionality  of  the  Test  Bed  (Figure  2-1). 

The  Test  Bed  hardware  architecture  supports  the 
interconnection  of  three  computer  systems  via  a  Local  Area 
Network  (LAN)  complemented  by  Vide  Area  Communication  Services. 
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Figure  2-1.  Interconnection  of  Heterogeneous  Systeas  via 
Local  Area  Network 
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The  three  computers  embedded  in  the  Test  Bed  are: 

1.  A  Honeywell  Level  6  computer  supporting  the  MCMM 
database  and  MCMM  application  programs. 

2.  A  VAX  11/780  oomputer  or  equivalent  supporting: 
e  Test  Bed  User  Interface 

e  Test  Bed  Common  Data  Model 
#  IDSS  2.0  and  its  database 

3.  An  IBM  3081  computer  supporting  an  MRP  package  to  be 
selected  in  conjunction  with  the  IPS  Project  Priority 
5501  team  (see  Figure  2-1). 

The  Test  Bed  makes  use  of  a  Local  Area  Network  to 
interconnect  the  Honeywell  Level  6  and  the  VAX  11/780  which  are 
in  close  geographical  proximity.  This  approach  offers  high 
throughput,  ease  of  installation,  expansion  capabilities,  and 
supports  the  process-to-process  communication  capabilities 
required  to  integrate  the  heterogeneous  databases  present  in  the 
Test  Bed  environment. 

The  Test  Bed  makes  use  of  Vide  Area  Communication  lines  to 
extend  the  functionality  and  usefulness  of  the  Test  Bed  to 
computers  which  are  geographically  remote. 

1.  A  synchronous  leased  line  provides  medium  speed 
communication  capabilities  to  the  General  Electric 
owned  IBM  3081  located  3  miles  away  from  the  computer 
center  used  to  develop  the  Test  Bed.  (Later  moved  to  Ge 
facility  in  Rockville,  Md.,  and  then  to  a  Boeing 
facility  in  Wichita,  Ka.) 

2.  Asynchronous  lines  are  provided  to  interconnect  the 
ICAM  (CIDS)  (Initial  Implementation)  and  ISMC 
development  computers  to  the  Local  Area  Network 
hardware,  as  well  as  to  interconnect  ISMC  development 
terminals  to  the  VAX  11/780  of  the  Test  Bed  through  the 
User  Interface. 

The  Test  Bed  hardware  architecture  allows  for  expansibility 
and  flexibility. 

1.  The  Test  Bed  hardware  architecture  can  be  expanded  to 
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the  MAX  Configuration  described  in  the  Threads 
Document.  Back  end  data  machines  and/or  additional 
general  purpose  computers  can  be  interconnected  via  the 
Local  Area  Network. 

2.  The  Test  Bed  hardware  architecture  can  be  expanded  to  a 
full  size  production  system  with  minimal  changes  to  the 
software . 

2. 3. 3. 2  Software  Architecture 

The  major  software  subsystems  are  also  indicated  in  Figure 

2-1 . 

2. 3. 2. 2.1  Distributed  Application  Data  on  Heterogeneous 
Databases 

The  application  data  are  distributed  in  heterogeneous 
database  management  systems,  themselves  resident  in 
heterogeneous  processors.  This  approach  allows  for  the 
integrated  query  of  existing  databases  by  new  integrated 
applications  without  conversion  of  the  database. 

2. 3. 3. 2. 2  Class  II  Data  Integration 

The  Test  Bed  software  and  system  utilities  support  Class  II 
(see  footnote,  page  1-1)  data  inquiries.  These  inquiries  may  be 
directed  toward  any  database  resident  in  the  Test  Bed,  and  are 
under  the  direct  control  of  the  Test  Bed  Common  Data  Model 
Processor.  System  utilities  perform  data  integrity  checks 
selectively  on  the  data  being  retrieved  in  the  system.  The 
early  implementation  of  the  Test  Bed  supports  updates  on  the 
databases  bound  to  the  Application  Subsystems.  Update 
activities  are  under  the  control  of  the  Application  Subsystems 
and  are  under  indirect  control  of  the  CDM  to  the  extent  that 
data  entry  and  messages  are  checked  by  the  CDM.  The  data 
integrity  checks  performed  include  edit,  domain,  and  range 
checking.  The  data  required  to  support  the  data  integrity 
checks  are  contained  in  the  Common  Data  Model  and  are  under 
control  of  the  Common  Data  Model  Administrator.  Data  inquiries 
use  the  Test  Bed  Neutral  Data  Manipulation  language  to  query 
Common  Data  contained  in  the  databases  integrated  by  the  Test 
Bed.  The  Test  Bed  Neutral  Data  Manipulation  Language  allows  the 
definition  of  nonprocedural  queries  which  are  independent  of  the 
structure  of  the  database(s)  being  accessed.  System  services 
allow  the  retrieval  of  data  contained  in  more  than  one  database 
in  more  than  one  system. 
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2. 3.3. 2.3  Pser  Interface  and  Data  Query  via  Preplanned 
Transactions 

In  the  early  1983  implementation,  user  interface  and  data 
query  are  accomplished  by  preplanned  transactions  and  messages. 
This  method  will  evolve  toward  ad-hoc  inquiries  as  development 
of  the  Test  Bed  continues  after  early  1983.  Information  queries 
via  preplanned  transactions  support  the  manufacturing  scenarios 
which  have  been  identified  and  constitute  a  natural  first  step 
toward  ad-hoc  query.  Message  integrity  oheoking  is  supported  by 
system  functions,  and  is  performed  selectively.  The  information 
required  to  support  the  message  integrity  checks  is  contained  in 
the  Common  Data  Model  and  is  under  the  oontrol  of  the  Common 
Date  Model  Administrator.  (Message  integrity  checking:  Future) 

2. 3. 3. 2. 4  Integration  and  Coordination  Through  the  Common  Data 
Model 

The  Common  Data  Model  is  a  resource  which  is  maintained  in 
a  centralized  fashion  to  support  the  following  functions: 

•  Define  logical  structure  of  the  information  common  to 
two  or  more  Application  Subsystems.  The  definition 
includes  entities,  their  attributes,  and  the 
relationships  between  entities. 

•  Define  the  domain  and  values  of  the  entities. 

•  Access  control  or  authorization  information  identifying 
the  operations  that  can  be  accessed  by  a  particular 
user . 

•  Define  the  format  of  the  data  as  stored. 

•  Catalog  of  Common  database  procedures  such  as  schema 
translation,  schema  definition.  Neutral  Data 
Manipulation  statement  translation,  data  translation 
procedures . 

•  Locate  the  specified  data  in  the  logical  data  structure 
(Test  Bed  Conceptual  Schema). 

•  Convert  query  requests  to  fit  the  locations  of  the  data 
and  the  required  processing. 

•  Aggregate  the  responses  from  the  various  databases. 
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•  Check  for  the  validity  and  completeness  of  update 
requests  (Class  II  environment). 

•  Support  the  user  interface. 

2. 3. 3. 2. 5  Integration  and  Coordination  Through  the  Integrated 
Network  Transaction  Manager 

The  Common  Data  Model  provides  a  repository  for  the  data 
describing  the  data,  procedures,  and  policies  shared  among  the 
various  IISS  Application  Subsystems. 

The  Network  Transaction  Manager  provides  the  operational 
implementation  of  the  above  concepts,  the  control  of  the 
execution  of  transactions,  the  control  of  the  flow  of  messages 
through  the  network,  the  restart  and  recovery  requirements,  and 
the  monitoring  of  performance. 

The  Network  Transaction  Manager  is  invoked  to  carry  out  the 
following  functions: 

•  Dispatch  of  messages  through  the  IISS  Network 

•  Follow-up  on  open  transactions 

•  Logging,  time  stamping  of  messages 

•  Monitoring  of  system  performance  (Future) 

•  System  synchronization 

•  Restart  of  the  IISS  system 

•  Restart  and  recovery  of  the  databases  (Future) 

•  Control  of  Application  Subsystems 

The  Network  Transaction  Manager  controls  the  execution  of 
application  subsystems  by  processing  the  Transaction  Message 
queues  built  on  each  node.  The  queues  provide  the  necessary 
buffering  action  resulting  from  the  asynchronous  nature  of  the 
Test  Bed  Application  Subsystem. 

2. 3. 3. 2. 6  Guaranteed  Delivery  of  Messages 


The  Network  Transaction  Manager  is  also  invoked  to 
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guarantee  the  delivery  of  ae&sages.  This  service  is  provided  to 
facilitate  the  migration  of  the  Test  Bed  to  the  Class  I 
environaent.  - 

This  capability  guarantees  that  aessages  will  be  delivered, 
even  if  the  destination  application  subsystea  is  teaporarily 
unavailable.  To  that  effect,  the  aessages  are  uniquely 
identified  at  the  level  of  the  IISS  by  Journalising  the  aessage 
type  and  Application  Subsystea  of  origin,  and  by  tiae  staaping. 
Tiae  staaping  and  journalising  allow  for  the  chronological 
reconstruction  of  the  transaction  input  streaa.  This  technique 
supports  the  recovery  of  unavailable  nodes  or  Application 
Processes . 

It  should  be  further  noted  that  the  systea  can  guarantee 
that  the  aessage  was  given  to  the  destination  process,  and  even 
that  the  process  acknowledged  having  ooapleted  processing.  The 
systea  cannot,  however,  guarantee  that  the  receiving  process 
actually  did  process  the  aessage  and  perfora  the  requested 
functions,  or.  for  that  natter,  that  the  aessage  was  even  read. 
The  proper  processing  of  aessages  is  totally  dependent  on  the 
receiving  application  prooess  and  cannot  be  controlled  or 
guaranteed  by  the  IISS  systea. 

2. 3. 5. 2. 7  Standard  Dser  Interface 

Test  Bed  User  Interface 


A  Test  Bed  User  Command  Language  simplifies  the  task  of  the 
user  when  interacting  with  the  Test  Bed.  User  inputs  are 
through  a  forns  systea  including  menus,  formatted  data  displays, 
and  foras  for  data  entry.  The  inputs  are  then  formulated  into 
standard  aessages  that  are  sent  to  the  application  processes  in 
the  proper  host  computer . 

The  User  Interface  thus  provides  a  unified  format  to  invoke 
Test  Bed  Systea  Utilities  as  well  as  to  support  the  user 
dialogues  of  Application  Subsystems  specifically  designed  for 
the  Test  Bed. 

Virtual  Terminal 


The  proliferation  of  terminal  hardware  and  the  wide 
disparity  in  capabilities  and  features  of  commercially  available 
terminals  create  an  interfacing  problem  between  IISS  and  its 
terminals . 
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This  problem  is  resolved  by  defining  a  specific  set  of 
terminal  features  and  protocols  which  must  be  supported  by  the 
IISS  software.  This  set  of  features  and  protocols  constitutes 
the  IISS  virtual  terminal  definition. 

Specific  terminals  are  then  mapped  against  the  IISS  virtual 
terminal  software  by  specific  software  modules  written  for  each 
type  of  real  terminal  interfaced  to  IISS.  This  approach  is 
consistent  with  the  layered  software  philosophy  of  IISS  since  it 
permits  the  interfacing  of  a  wide  variety  of  terminals  without 
changes  to  the  IISS  application  programs. 

System-Wide  Forms  and  Protocols 

User  forms  and  user  protocols  are  defined  at  the  IISS 
system  level.  These  forms  and  protocols  define  the  manner  in 
which  the  IISS  user  interfaces  with  IISS.  The  forms  are  data 
structures  with  attributes  which  are  enforced  by  the  forms 
package.  Mandatory  fields,  alphanumeric  fields,  and  numeric 
only  fields  are  examples  of  the  attributes  which  are  enforced  by 
the  forms  package. 

The  forms  and  protocols  are  defined  by  data  stored  in  the 
CDM .  and  as  such  are  very  flexible  and  extensible. 
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SECTION  3 
REQUIREMENTS 


3.1  System  Definition 

3.1.1  Network  Transaction  Manager  Configuration  Item 

3. 1.1.1  Network  Transaction  Manager  Mission  Statement 

The  Test  Bed  is  a  distributed  oomputer  system  made  up  of 
cooperating  processes.  As  an  example  of  cooperating  processes, 
consider  the  processing  of  a  distributed  query.  In  this 
example,  processes  resident  on  several  hosts  are  cooperating  in 
the  retrieval,  selection,  unit  and  format  conversion  of  data 
resident  on  several  databases. 

The  Network  Transaction  Manager  performs  the  coordination, 
communication  and  housekeeping  functions  required  to  integrate 
the  Application  Processes  and  System  Servioes  resident  on  the 
various  hosts  into  a  cohesive  system.  The  management  of  mail 
boxes,  message  queues,  application  processes,  to  name  a  few,  are 
examples  of  System  Services  provided  by  the  Test  Bed. 

3. 1.1. 2  Network  Transaction  Manager  Functional  Areas 

The  configuration  tree  of  the  NTM  is  shown  in  Figure  3-1. 
Figure  3-1  shows  three  major  functional  areas: 

•  Manage  Message 

•  Manage  Processes 

•  Maintain  Operability 

The  Test  Bed  is  a  message-driven  system.  The  Test  Bed  uses 
messages  to  request  the  execution  and  termination  of  Application 
Processes  and  system  services.  Messages  are  also  used  to 
exchange  data  between  Application  Processes  and  System  Services. 

The  Manage  Message  functional  area  of  the  Network 
Transaction  Manager  is  responsible  for  the  management  of  these 
messages . 


The  Application  Processes  resident  on  the  Test  Bed  need  to 
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be  managed  according  to  the  processing  needs  of  the  environment. 
Managing  Applications  include  functions  such  as  loading, 
initiation,  and  terminating  processes.  These  functions  are 
included  in  the  Manage  Processes  functional  anea  of  the  Network 
Transaction  Manager. 

The  Maintain  Operability  functional  area  of  the  MTM 
contains  the  functions  required  to  create,  modify,  maintain  the 
processing  environment  of  the  Test  Bed.  The  creation, 
modification  and  maintenance  of  the  processing  environment  calls 
for  processing  capabilities  to  support  startup,  shutdown, 
recovery  and  monitoring  of  the  Test  Bed. 

3. 1.1. 3  network  Transaction  Manager  Operational  Scenario 

The  Network  Transaction  Manager  Operational  Scenarios 
presented  here  are  introduced  for  the  sole  purpose  of  supporting 
the  identif icatior.  of  the  functional  specifications  to  be  met  by 
the  Network  Transaction  Manager.  These  scenarios  are  not  meant 
to  imply  a  specific  implementation  of  these  functional 
specifications.  Consequently,  the  final  design  of  the  Network 
Transaction  Manager  may  implement  scenarios  which  differ  from 
the  scenarios  shown  in  this  subsection. 

3. 1.1. 3.1  NTM  Environment 

To  describe  the  environment  of  the  NTM,  it  is  necessary  to 
introduce  the  concept  of  an  AP  Cluster. 

On  an  intuitive  basis,  an  AP  Cluster  consists  of  processes 
related  to  one  application  as  viewed  by  the  user.  Examples  of 
Test  Bed  AP  Clusters  are  the  MCMM,  the  MRP,  and  the  IDSS  AP 
Clusters.  The  formal  definition  of  the  AP  Cluster  concept  is 
given  in  Section  2.  In  the  Test  Bed,  every  Application  Process 
is  uniquely  addressable . 

Communications  and  Control  with  each  AP  Cluster  is 
accomplished  via  Network  Transaction  Manager .  In  the  Test  Bed 
environment,  the  AP  Clusters  may  reside  on  different  hosts,  thus 
the  various  instances  of  the  NTM  may  present  some  differences  to 
reflect  the  different  operating  system  environments  in  which 
they  happen  to  operate. 
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3. 1.1. 3. 2  NTM  Architecture 

The  AP  Cluster  concept  introduced  above  offers  the 
following  significant  advantages: 

1.  The  Application  Processes  which  most  frequently  access 
a  database  are  grouped  on  the  AP  Cluster  containing  the 
database  supporting  these  processes.  This  grouping 
minimizes  the  frequency  of  off -host  data  accesses. 

2.  An  instance  of  the  NTH  is  associated  with  each  AP 
Cluster  to  simplify  the  message  traffic.  All 
communications  related  to  one  AP  Cluster  are  routed 
through  that  AP  Cluster  NTH.  This  approach  streamlines 
the  type  of  communi cat ions  which  must  be  supported. 

This  concept  is  graphically  illustrated  on  Figure  3-2 
and  on  Figure  3-3.  The  first  figure  shows  a  system 
which  allows  the  Application  Processes  to  Communicate 
directly  with  one  another.  The  second  figure  shows  a 
system  which  routes  all  communications  through  specific 
communication  programs.  This  second  approach  is 
retained  for  the  Test  Bed,  and  is  illustrated  on  Figure 
3-4.  This  last  figure  shows  the  impact  of  the  multi 
host  environment  of  the  Test  Bed  on  the  Architecture  of 
the  Communication  and  NTM  Subsystems. 

More  specifically.  Figure  3-4  shows  that  not  only  each  AP 
Cluster  has  its  own  NTM,  but  that  in  addition,  each  host  owns  an 
additional  AP  Cluster,  with  its  own  NTM,  to  communicate  with  all 
other  hosts.  The  AP  Cluster  used  to  communicate  with  other 
hosts  is  called  the  COMM  AP  Cluster. 

The  above  concepts  and  definitions  lead  to  Figure  3-5 
showing  a  conceptualization  of  the  NTM  architecture.  The  key 
features  of  this  figure  are: 

1.  The  User  Interface  AP  Cluster,  and  Virtual  Terminal 
Interface 

2.  The  CDM  Processor  AP  Cluster 

3.  The  NTM  operator  AP  Cluster 

4.  The  NTM  supports  communications  between  any  two  AP 
Clusters  shown  on  the  diagram 


This  figure  is,  however,  a  conceptualization.  The  cross 
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Figure  5-2.  Cluster  APs 

bar  aatrix  arrangement  shown  has  no  iaplioation  on  the 
architecture  of  the  Test  Bed.  The  Test  Bed  NTH  architecture  is 
more  faithfully  represented  on  Figure  5-4.  The  Communication 
Subsystem  described  in  Seotion  5.1.5  supports  the  architecture 
of  Figure  5-4. 

The  interaction  of  the  NTM  and  its  environment  is  depicted 
on  the  IDEFO  diagram  shown  in  Figure  5-6.  With  respect  to  this 
diagram,  the  following  observations  are  made: 

1.  All  messages,  whether  Inter  or  Intra  AP  Cluster 
messages,  are  received  and  handled  by  the  NTH . 

2.  The  NTH  places  requests  to  the  host  operating  systems 
to  initiate  and/or  abort  specific  Application 
Processes . 

3.  The  NTH  receives  status  information  from  the  host 
operating  system. 


3-5 
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Figure  S-3.  Ease  in  Implementation 

4.  The  HTM  delivers  messages  to  the  Application 
Processes.  These  messages  nay  be  viewed  as  input  data 
to  the  Application  Process. 

5.  The  HTM  receives  nessages  from  the  Application 
Processes.  These  nessages  may  be  viewed  as  output 
data  from  the  Application  Processes. 

6.  The  HTM  transmits  all  messages  to  their  destinations, 
whether  inter  or  intra  off  AP  Clusters. 

Figure  3-7  and  3-8  are  variations  on  the  theme  shown  in 
Figure  3-9.  Figures  3-7  and  3-8  are  drawn  for  the  COMM  (inter 
host)  Application  Process  and  for  the  User  Interface.  From  an 
HTM  point  of  view.  Figures  3-6,  3-7,  and  3-8  are  identical.  From 
an  Application  point  of  view,  Figures  3-7  and  3-8  show  the 
additional  input/output  requirements  specific  to  the  User 
Interface  and  COMM  AP  Clusters. 


3-6 
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Figure  5-4.  Host  1 

3. 1.1. 3. 3  HTM  Functional  Description 

Figure  3-9  is  the  Top  level  of  an  IDEFO  diagram  portraying 
the  functionality  of  the  HTM.  This  diagram  shows  the  three 
major  functional  areas  identified  earlier  and  their  interaction. 

Figure  3-10  details  the  MANAGE  Message  functional  area. 

This  figure  shows  that  messages,  once  received  by  the  HTM,  are 
checked  for  authorization,  logged  and  routed.  A  message  header 
is  appended  by  the  HTM  to  facilitate  the  routing  and 
interpretation  of  the  message.  At  this  level  of  description, 
the  Route  and  Send  Message  function  includes  the  routing  and 
sending  of  a  message  to  an  off  AP  Cluster,  on  AP  Cluster,  or 
maintain  operability  Application  Processes. 

Figure  3-11  details  the  Manage  Processes  functional  area. 
This  figure  shows  that  messages  are  interpreted  and  either  used 
to  control  Application  Processes  or  to  communicate  with 
Application  Processes. 


MTM  (USER  VIEW) 


Figure  3-5.  IISS  Architecture  -  Conceptual  Model 
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The  Initiate  Application  Process  function  includes  the 
scheduling  of  such  initiation.  The  scheduling  information  is 
contained  in  the  message  initiating  the  process. 

The  Abnormally  Terminate  Application  Process  functions 
include  the  termination  of  an  Application  Process  and  the 
housekeeping  actvities  related  to  such  termination.  In  the  Test 
Bed.  termination  of  an  Application  Process  may  be  accompanied  by 
the  termination  of  the  query  processors  and  data  aggregators 
initiated  by  that  Application  Prooess.  Data  aggregators,  and 
query  processors  are  described  in  Seotion  5.1.2.  The  infor¬ 
mation  required  to  keep  track  of  active  query  processors  and 
data  aggregators  is  maintained  by  the  HTM.  For  example,  a 
chained  list  links  the  various  processes  (query  processors,  data 
aggregators,  transformers)  to  the  Application  Prooess  which 
required  these  services. 

Figure  3-12  details  the  Communicate  with  Application 
Process  function.  Messages  are  accepted  from  and  delivered  to 
Application  Processes.  Messages  are  also  paired  on  an 
Application  Process  basis.  This  supports  the  detection  of 
unanswered  messages  and  the  initiation  of  corrective  action,  by 
the  receiver,  in  the  event  of  a  time  out.  The  NTH  message 
pairing  capabilities  allow  the  detection  of  end  to  end  problems 
(such  as  the  failure  of  one  Application  Process  to  return  an 
expected  reply)  as  well  as  to  detect  host  and  local  area  network 
failures.  The  NTH  on  the  originating  AP  Cluster  detects  time 
out  conditions  and  reports  the  time  out  to  the  process  which 
originated  the  message. 

The  detection  of  malfunctions  in  the  LAM  is  performed  by 
the  COMM  subsystems. 

Figure  3-13  details  the  Maintain  Operability  functional 
area.  This  functional  area  is  shown  to  breakdown  into  the 
following  key  functions;  and  relates  to  the  IISS  System 
Software: 

•  Start  up  (IISS  on  host) 

•  Restart 

•  Shutdown  (IISS  on  host) 

•  Test  Bed  Recovery 

•  Monitor  and  Record  Resource  Usage 
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The  Maintain  Operability  functions  are  also  shown  to 
coaaunicate  with  the  IISS  operator.  The  operator  acts  as  the 
controller  of  the  Maintain  Operability  of  the  IISS  Systea 
Software,  and  as  such  is  the  recipient  of  the  aaintain 
operability  status  messages  issued  by  the  Systea  Software. 

These  aessages  aay  also  be  stored  in  a  file  for  archive  and 
analysis  purposes.  Status  aessages  issued  by  user  supplied 
Application  Processes  are  routed  to  the  user  by  the  IISS 
software . 

The  availability  of  Application  Processes  and  IISS  status 
and  error  inforaation  is  dependent  upon  the  services  provided  by 
the  host  operating  systeas.  Consequently  the  extent  and 
availability  of  such  inforaation  varies  froa  operating  systea  to 
operating  systea.  Status  and  error  inforaation  is  gathered  via 
a  combination  of  IISS  and  host  operating  utilities  according  to 
host -dependent  procedures. 

The  Recovery  function  addresses  the  reoovery  of  the  Test 
Bed  system  and  its  databases.  The  reoovery  of  the  databases 
themselves  is  achieved  via  the  roll  back  and  Journalisation 
facilities  provided  by  the  various  database  managers.  One  of 
the  NTM ' s  role  is  to  ensure  the  synchronisation  of  the  recovery 
operations  and  to  initiate  the  recovery  once  the  systea  is  at  a 
quiet  point. 

3. 1.1. 3. 4  NTH/ IISS  Start  Op  Scenario 

The  NTH 7 IISS  start  up  scenario  listed  here  is  given  for  the 
6201H  implementation  of  the  Test  Bed.  The  current  design  calls 
for  the  start  up  of  the  Test  Bed  to  be  initiated  froa  the  host 
consoles.  A  start  up  command  must  be  typed  on  each  of  the  host 
consoles.  Subsequently,  the  Test  Bed  aay  allow  for  a 
centralized  start  up  of  the  system  (Figure  3-14). 

The  start  up  of  the  Test  Bed  Software  is  thus  as  follows: 

1.  On  the  VAX: 

The  IISS  operator  initiates  the  "START  IISS"  procedure 
file  under  control  of  VAX  VMS. 

This  procedure  starts  up  the  following  A!  Clusters: 
a.  Common  Data  Model  Request  Processor 


b.  User  Interface 
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c.  Any  NTM  (for  example,  IDSS) 

d.  The  COMM  Work  Stations  with  the  VAX/Honeywell  and 
VAX/IBM  oouun i cat i on  services 

Each  AP  Cluster  initiates  its  own  request  for  CDM  data 
to  the  CDM  request  processors.  On  completing  its 
prescribed  start  up  steps,  each  AP  Cluster  reports  its 
status  to  the  oonsole  used  to  initiate  the  start  up. 

The  above  step  then  initialises  the  NTM  tables,  the  VTI 
configuration  tables  and  the  User  Interface  local  fora 
storage.  Any  information  required  by  the  user  work 
station  NTM  is  down  loaded  from  the  CDM. 

On  the  Honeywe 1 1 : 

The  IISS  Operator  initiates  the  “START  IISS"  procedure 
file  under  control  of  GCOS  MOD400  from  a  Honeywell 
console . 

This  GCOS  MOD400  procedure  file  starts  up  the  following 
AP  Clusters: 

a.  The  COMM  Work  Station  with  the  Honeywe 1 1/VAX  and 
Honeywell /IBM  communication  services 

b.  Any  User  work  station  NTM  (for  example.  MCMM) 

Each  AP  Cluster  initiates  its  own  request  for  CDM  data 
to  the  CDM  processor.  On  completing  its  prescribed 
start  up  step,  each  AP  Cluster  reports  its  status  to 
the  console  of  the  Honeywell.  The  above  steps 
initialize  the  NTM  tables.  The  AP  Clusters  are  started 
in  the  sequence  listed  above.  The  Honeywel 1 /VAX  COMM 
AP  Cluster  must  be  operational  for  the  Honeywell  start 
up  to  proceed.  As  each  AP  Cluster  becomes  operational, 
it  notifies  VAX  IISS  console.  In  the  event  of 
difficulties,  the  error  messages  generated  during  start 
up  are  displayed  on  the  Honeywell  console. 

On  the  IBM  3033: 

The  start  up  procedure  described  above  is  repeated  on 
the  IBM  3033.  The  procedure  is  initiated  under  control 
of  MVS  from  an  IBM  console. 

The  AP  Clusters  brought  up  on  the  IBM  3033  are: 
a.  The  COMM  Work  Station  with  the  Honeywel 1 /VAX  and 
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Figure  3-13.  Communicate  with  Application  Processes 
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Honeywell /IBM  communication  services 
b.  Any  User  Work  Station  NTM  (for  example,  MRP) 

3. 1.1. 3. 5  HTM/IISS  Shut  Down  Scenario 

The  shut  down  of  the  IISS  system  can  be  initiated  from  any 
IISS  terminals  by  an  IISS  operator  with  the  proper  author¬ 
ization.  The  shut  down  is  graceful  and  complete.  To  that 
effect,  the  following  capabilities  are  provided: 

1.  Warning  messages  are  sent  to  all  IISS  terminals.  These 
messages  are  repeated  at  reasonably  spaced  time 
intervals . 

2.  Further  IISS  logins  are  disabled  when  a  system  shut 
down  is  in  process. 

3.  Processes  are  allowed  to  run  toward  completion  for  a 
reasonable  grace  period  (for  example,  15  minutes). 

This  includes  the  query  processors  and  data  aggregators 
initiated  by  the  Application  Processes. 

4.  Status  of  queues  are  saved  on  each  processor.  (Not 
implemented,  nor  possibly  desireable  in  near  future) 

5.  Processes,  data  aggregators ,  query  processors  still 
running  at  the  end  of  the  grace  period  are  killed  under 
IISS  operator  control . 

6.  The  shut  down  process  proceeds  first  with  the 
termination  of  User  Application  Processes,  and  second 
with  the  termination  of  Test  Bed  Services. 

7.  A  message  is  sent  to  the  host  console  upon  completion 
of  the  shut  down . 

8.  The  shut  down  of  the  IISS  system  can  be  initiated  on  a 
host  by  host  basis  from  the  host  consoles.  This 
capability  serves  as  a  back-up  in  the  event  of  LAN  and 
communication  malfunctions. 

3. 1.1. 3. 6  NTM/ IISS  Host  Shutdown  Scenario 

The  shut  down  of  a  selected  host  of  the  Test  Bed  proceeds 
with  the  same  logic  that  followed  for  the  shutdown  of  the  entire 
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Test  Bed.  In  fact,  the  shutdown  of  the  entire  Test  Bed  is 
viewed  as  the  shutdown  of  each  host,  per  the  above  scenario.  The 
shutdown  procedures  are  described  in  the  operator's  manual . 

The  following  steps  are  carried  out  during  the  shutdown  of 
the  Test  Bed  software: 

1.  The  status  of  the  message  queues  are  checkpointed  (Mot 
implemented) 

2.  The  application  processes  still  running  at  the 
expiration  of  the  shutdown  count  down  period  are  killed 
under  supervision  of  the  IISS  operator. 

3.  The  Test  Bed  System  Services  (MTM,  OP  AP  Cluster,  COMM 
AP  Cluster,  etc.)  are  terminated. 

The  above  steps  are  repeated  on  each  host. 

3. 1.1. 3. 7  NTH/ IISS  Host  Start  Op  Scenario 

By  the  same  reasoning,  the  start  up  of  a  selected  host  is 
performed  as  explained  in  the  section  entitled  "NTM/IISS  Start 
Up  Scenario".  The  scenario  is,  however,  limited  to  one  host. 

The  start  up  of  any  host  other  than  the  CDM  does  not  progress 
past  the  request  for  CDM  data  if  the  CDM  host  is  not  already  up. 

3. 1.1. 3. 8  IISS  Recovery  Scenario 

The  IISS  Recovery  Scenario  is  not  addressed  in  the  early 
release  of  the  Test  Bed.  Definition  of  the  functionality  and 
implementation  of  the  recovery  mechanism  is  an  enhancement  to 
the  Test  Bed. 

3. 1.1. 3. 9  Application  Process  Scheduling 

The  NTM  initiates  Application  Processes  at  the  request  of 
the  Test  Bed  user  or  at  the  request  of  Application  Processes 
already  running.  The  initiation  of  the  data  aggregators  and 
query  processors  are  examples  of  this  second  eventuality.  The  4 

initiation  of  the  Application  Process  is  only  performed  for 
authorized  requests.  The  initiation  is  prioritized  and  proceeds 
on  a  FIFO  basis  at  equal  priority.  The  execution  of  some 
Application  Processes  may  be  linked  to  wall  clock  time,  time 
delay,  or  may  be  conditional  to  some  event. 

The  information  required  to  control  the  initiation  of 
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Application  Processes  (priority,  schedule,  condition)  is  carried 
by  the  Application  Process  request  message. 

Consider  Figure  3-15.  The  scheduling  of  the  Application 
Process  initiation  is  controlled  by  the  scheduler.  The 
scheduler  keeps  an  on-going  watch  of  the  Application  Process 
queues  containing  the  requests  for  start  up  time  and  may  be 
deactivated  when  the  system  is  executing  a  Quiet  Point  Command 
or  when  the  system  is  about  to  be  shut  down.  The  scheduler  may 
be  reactivated  upon  Command  to  resume  processing  of  Test  Bed 
Application  Processes. 

The  NTH  supports  multiple  instances  of  a  given  Application 
Process.  Multiple  instances  of  Application  Processes  may  be 
created  in  response  to  requests  from  multiple  users. 

The  NTH  automatically  initiates  additional  instances  of 
application  processes  which  have  been  granted  the  privilege  to 
have  multiple  instances.  This  privilege  is  declared  in  the  CDM. 
The  data  describing  the  Application  Processes  defines  the 
maximum  number  of  instances  which  can  be  running  simultaneously. 
The  CDM  Administrator  authorises  the  duplication  of  selected 
Application  Processes. 

3.1.1.3.10  Maintain  Directory  of  Active  Application  Processes 

The  HTM  receives  status  information  from  the  operating 
system  of  the  local  hosts.  This  information  is  used  to  create 
and  to  maintain  a  list  of  active  application  processes  on  the  AP 
Cluster.  This  li6t  is  used  to  clean  up  an  AP  Cluster  whenever 
an  Application  Process  is  aborted  or  terminates. 

3.1.1.3.11  Maintain  Directory  of  Offspring  Application 
Processes 


The  Test  Bed  Application  Processes  generate  offspring 
application  processes  whenever  they  perform  a  distributed  query 
or  update.  In  the  distributed  query  environment,  these 
offsprings  include  data  aggregators  and  query  processors.  The 
HTM  maintains  a  list  of  the  data  aggregators  and  query 
processors  which  have  been  requested  by  the  query  scheduler. 
This  list  is  used  to  abort  the  data  aggregators  and  query 
processors  in  the  event  that  the  parent  Application  Process 
terminates  or  is  aborted.  The  list  identifies  the  offspring 
application  process,  the  target  AP  Clusters  and  the  parent 
Application  Process. 
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3.1.1.3.12 


>lication  Process  Termination 


For  integrated  Application  Processes,  the  normal  and 
abnormal  termination  of  an  Application  Process  is  known  to  the 
NTM .  The  NTM  receives  status  information  from  the  local  host 
operating  system.  The  NTM  provides  the  following  services  upon 
the  termination  of  an  Application  Process: 


1.  Normal  Termination 

The  name  of  the  Application  Process  that  terminates  is 
removed  from  the  AP  Cluster  active  application  process 
list.  Usage  statistics  for  the  Application  Process  are 
recorded . 


2.  Abnormal  Termination 

In  the  event  of  abnormal  termination  of  an  Application 
cancelling  the  active  offsprings  of  that  Application 
Process  which  may  still  be  active  or  queued  up  for 
execution.  The  NTM  performs  this  task  by  taking 
advantage  of  the  offspring  application  process  list  to 
notify  the  AP  Clusters  which  may  be  processing  or  about 
to  process  the  aborted  Application  Process  offspring 
application  processes.  The  NTM' s  on  these  AP  Process, 
the  NTM  assumes  the  responsibility  for  Clusters  make 
use  of  the  active  application  process  directory  to 
abort  active  offsprings  (data  aggregators,  query 
processors)  or  to  remove  these  offsprings  from  the 
spawning  request  queues . 

The  NTM’s  of  the  offspring  nodes  report  the  completion 
of  the  clean  up  operation  to  the  NTM  of  the  cancelled 
Application  Process  AP  Cluster.  The  abnormal 
termination  process  continues  with  the  steps  described 
under  the  normal  termination  scenario . 


3.  Housekeeping 

The  IISS  operator  may  invoke  the  abnormal  termination 
process  described  above  to  free  the  system  from 
Application  Processes  and  Offsj-ing  Processes  which 
have  not  been  cancelled  following  the  normal 
termination  of  an  Application  Process.  This 
eventuality  may  occur  with  improperly  written 
Application  Processes  or  in  the  event  of 
hardware/ software  failures. 
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3.1.1.3.13  Exception  Handling 

The  NTH  is  actively  involved  in  the  handling  of  exception 
calls  nade  by  an  AP  Cluster  Application  Process  to  the  local 
host  operating  system.  For  the  Test  Bed  to  act  as  a  cohesive 
and  robust  system,  the  following  functions  need  to  be  performed: 

1.  The  occurrence  of  an  exception  call  in  an  Application 
Process  must  be  reported  to  the  initiator  (person  or 
software)  of  that  Application  Process.  The  report  must 
include  sufficient  information  for  the  initiator  to 
decide  on  a  course  of  action. 

2.  The  report  must  be  in  a  standard  format  so  that  the 
interpretation  of  the  error  condition  is  not  dependent 
upon  the  host  on  which  it  occurred. 

3.  Exception  calls  must  be  logged  for  further  analysis  and 
trouble  shooting. 

The  above  functions  are  implemented  on  the  Test  Bed  by 
allowing  the  NTH  to  intercept  the  exception  calls  to  the 
operating  system.  Thus  the  NTH  can  notify  the  initiator  of  the 
Application  Process  of  the  type  of  error  which  occurred.  The 
local  error  codes  are  first  converted  to  the  Test  Bed  (Neutral) 
error  codes .  The  Test  Bed  error  codes  and  the  host  error  code 
mapping  information  are  contained  in  the  CDM.  Exception  calls 
originating  in  the  Test  Bed  system  service  software  are  reported 
to  the  IISS  operator.  Such  calls  could  indicate  serious 
problems  with  the  IISS  system  software. 

3.1.1.3.14  Communication  with  Application  Processes 

The  NTH  communicates  with  Application  Processes  via  mail 
boxes.  These  mailboxes  are  named,  created  and  operated  via  the 
primitives  described  in  Section  3.1.5  (Communication  Subsystem). 
The  primitives  described  in  Section  3.1.5  support  multiple 
instances  of  the  same  Application  Process. 

3.1.1.3.15  Message  Authorization 

The  NTM  is  the  funnel  through  which  all  Test  Bed  messages 
flow.  This  is  the  natural  place  for  message  authorization 
enforcement.  In  the  Test  Bed  data,  access  privileges  are 
granted  to  Application  Process  via  the  schema  granted  to  it,  and 
security  is  enforced  by  controlling  the  access  to  the 
Application  Processes  themselves. 
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Consider  Figure  3-16.  This  figure  shows  the  various  data 
access  mechanisms  used  in  the  Test  Bed. 

Application  Process  Humber  One  (APP1)  has  been  granted 
access  to  databases  1  and  2,  via  the  external  schema  granted  to 
it  by  the  CDM  Administrator.  The  precompiler  has  generated  the 
query  processors  QP11  and  QP12.  APP1  can  thus  invoke  these  two 
query  processors.  If  User  1  has  been  granted  aocess  rights  to 
APP1 ,  it  thus  can  query  databases  1  and  2. 

Assume,  for  the  sake  of  discussion,  that  User  2  has  not 
been  granted  access  rights  to  databases  1  and  2,  and  henoe  does 
not  have  the  schema  information  required  to  precompile  the 
necessary  query  processors  QP21  and  QP22  required  to  aocess 
databases  1  and  2  from  an  Application  Process  to  which  he  has 
access  privileges. 

User  2  can  thus  only  gain  access  to  database  1  and  2  by 
invoking  directly  or  indirectly  an  Application  Process  such  as 
APP1 .  The  direct  accessing  of  QP11  and  QP12  is  not  deemed 
feasible  since  these  two  precompiled  query  processors  are  tied 
(message  destination,  oontrol)  to  APPL.  In  the  Test  Bed.  each 
Application  Process  and  each  user  is  granted  through  its  legal 
user  role  authority  to  send  and  authority  to  receive  messages 
from  and  to  other  users.  This  scheme  is  used  to  prevent  the  two 
access  paths  shown  in  dotted  lines  on  Figure  3-16.  The  NTH  is 
charged  with  enforcing  the  transmit  and  receive  rights  of  each 
application,  by  comparing  the  source  and  destination  information 
contained  in  the  message  with  the  authority  to  send  and 
authority  to  receive  granted  to  each  U6er.  This  information  is 
defined  in  the  CDM  by  the  CDM  Administrator.  All  communications 
between  Application  Processes  are  routed  via  the  NTM. 

The  above  scheme  can,  however,  be  easily  defeated.  If  APP1 
creates  a  private  copy  of  the  data,  no  control  on  the  access  to 
this  private  copy  can  be  exercised  through  the  Test  Bed  system. 
Administrative  procedures  or  other  automated  procedures  (prepass 
of  the  code)  can  be  used  to  disallow  this  possibility. 

3.1.1.3.16  Message  Header 


The  NTM  appends  a  header  on  all  messages  it  receives  from 
the  Application  Processes.  This  approach  allows  for  the 
layering  of  protocols. 

For  example,  the  header  contains  the  message  category, 
source,  destination  information  and  various  flags  (logging. 
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statistics,  etc.)  controlling  the  kind  of  message  handling 
services  to  be  invoked. 

The  NTH  strips  the  header  before  handing  the  message  over 
to  its  destination. 

3.1.1.3.17  Message  Logging 

The  NTH  serialises  and  logs  messages.  The  logs  are  kept  on 
the  host  where  the  message  originates.  The  message  serial 
number  is  the  concatenation  of  the  AP  Cluster  identification 
number  and  of  the  serial  number  sequentially  assigned  to  the 
message  in  the  AP  Cluster  where  it  originates.  Messages  are 
time  stamped  as  necessary.  The  time  stamps  are  obtained  from 
the  host  system  clock  and  specify  date,  time  of  day. 

3.1.1.3.18  Message  Routing 

The  NTM  routes  the  messages  to  their  final  destination. 

To  that  effect,  the  NTM  appends  a  physical  address  to  the 
message.  The  message  physical  address  is  derived  from  the 
logical  address  supplied  by  the  user  and  from  the  logioal  to 
physical  maps  provided  by  the  CDM.  Undefined  logical  addresses 
are  flagged  to  the  user. 

The  user  supplies  a  logical  address  which  uniquely 
identifies  the  Application  Process  at  the  system  level. 

The  system,  however,  through  the  mapping  tables  defined  in 
the  CDM  will  expand  this  logical  address  to  a  physical  address. 

The  NTM,  through  the  mail  box  naming  rules,  establishes  the 
proper  end  to  end  correspondence  which  exists  at  any  point  in 
tine  between  the  various  instances  of  cooperating  Application 
Processes . 

The  above  concepts  are  reflected  in  Figures  3-17  and  3-18. 

3.1.1.3.19  Message  Pairing 

The  NTM  pairs  messages.  That  is,  it  keeps  track  of  the 
request  and  response  message  pairs  flowing  through  the  system. 

A  time  out  allows  the  detection  of  unanswered  messages.  The 
Application  Processes  which  initiated  the  unanswered  request 
message  of  a  message  pair  is  notified  of  the  time  out.  It 
initiates  any  recovery  or  contingency  action  it  may  support. 
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UNAUTHORGE) USER  2 
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AUTHCnZED 
ACCESS 


Figure  3-16.  Message  Authentication 
3.1.1.3.20  Error  Logging 

The  NTH  logs  errors  in  am  error  file.  A  file  is  Maintained 
on  each  host  and  can  be  accessed  centrally  by  the  XISS  operator. 
The  file  can  be  cleared  under  control  of  a  procedure  activated 
by  the  operator.  The  files  are  maintained  locally  to  increase 
the  likelihood  of  capturing  error  nessages.  (See  Section 
3. 1.1. 3. 3) 
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3.1.1.3.21  Message  Integrity  Checking 

Message  integrity  checking  enhances  the  reliability  and 
security  of  the  Test  Bed  system.  Message  header  integrity 
checks  are  performed  by  the  NTM .  Message  data  integrity  checks 
are  performed  by  the  destination  Application  Subsystem.  These 
checks  are  supported  by  Common  Data  or  by  Private  Data  known  to 
the  subsystem.  The  NTM  checks  the  data  targeted  to  its  own  use. 

1.  Integrity  Checking  of  the  Header 

This  type  of  integrity  check  is  performed  by  the  NTM  of 
the  AP  Cluster  originating  the  message,  and  is 
performed  in  inter  host  as  well  as  intra  host 
communications . 

For  example,  the  header  integrity  check  includes  the 
following  checks: 

a.  Edit  of  each  field 

b.  Reasonableness  of  the  user-defined  fields 

In  the  event  of  errors,  the  sender  is  notified.  The 
correction  of  the  errors  is  left  to  the  sender.  The 
error  message  is  logged  in  the  Test  Bed  error  file. 

2.  Integrity  Checking  of  the  Data  Section  of  NTM  Bound 
Messages  (Future) 

This  type  of  integrity  checking  is  performed  by  the 
receiver  of  the  message.  The  data  supporting  this 
integrity  check  is  supplied  to  the  NTM  by  the  CDM ,  on 
an  AP  Cluster  basis  and  may  be  kept  locally  for 
performance  reasons.  The  types  of  data  integrity 
checks  include: 

a.  Number  of  data  elements  expected  in  the  message 

b.  Edit  of  each  data  element  (alphanumeric,  numeric, 
strings).  Each  data  element  editing  information 
describes  the  number  of  symbols  expected. 

c.  Range  check  of  each  data  element  (for  numeric  data 
types) 


d.  Domain  check 


AP  CLUSTER  NAME 
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Figure  3-17.  NTH  IDEF1  Concepts 


Figure  3-19.  End-to-End  Addressing 
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In  the  event  of  detected  errors ,  the  sender  of  the 
message  is  informed  of  the  presence  of  errors.  The 
correction  of  the  errors  is  left  to  the  transmitting 
Application  Program.  The  error  message  is  logged  in 
the  Test  Bed  error  file. 

3.1.1.3.22  Message  Guaranteed  Delivery 

When  requested,  the  NTM  guarantees  the  delivery  of  messages 
given  to  it  by  an  Application  Program.  Messages  to  be  handled 
in  a  guaranteed  delivery  mode  are  of  the  appropriate  message 
type  and  use  special  interface  services. 

Guaranteed  delivery  is  a  service  provided  by  the  NTM  for 
interhost  and  intrahost  communications  between  Application 
Process  Clusters  or  within  the  same  Application  Process 
Clusters.  Figure  3-20  shows  how  guaranteed  delivery  messages 
are  transmitted  and  acknowledged.  The  Application  Process  which 
originates  the  message  (source)  receives  acknowledgement  from 
NTM  1  after  the  message  has  been  Journalized  on  non-volatile 
memory  (File  1).  The  NTM  on  the  AP  Cluster  of  the  destination 
Application  Process  (NTM  2)  acknowledges  receipt  of  the  message 
after  the  message  has  been  Journalized  in  non-volatile  memory 
(File  2).  The  destination  process  acknowledges  receipt  of  the 
message  explicitly  (via  an  acknowledge  message)  to  the  AP 
Cluster  NTM  2. 

Attempts  to  deliver  the  message  are  initiated  when  either 
one  or  the  following  conditions  occurs: 

•  Message  is  first  received  by  NTM  1  or  by  NTM  2 

•  Destination  AP  Cluster  is  restarted 

•  Destination  Application  Process  is  initiated 

The  guaranteed  delivery  messages  are  time  stamped  and 
logged.  A  utility  allows  the  scanning  of  the  log  and  extracting 
the  messages  whose  ages  exceed  a  given  threshold.  Such  messages 
are  displayed  on  the  IISS  operator  console  for  disposition  by 
the  IISS  operator.  The  display  includes  the  following 
information: 


•  Time  stamp 

•  Source,  destination 
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•  Full  message  contents 

3.1.1.3.23  System  Statistics  Gathering 

The  NTH  gathers  the  following  system  usage  statistics: 

•  Message  type,  serial  number,  time  6tamp 

e  Application  Process  start  and  stop  time 

The  MTM  statistics  gathering  capabilities  oan  be  controlled 
on  a  message-by-message  basis  or  on  a  system  wide  basis  through 
NTH  configuration  data  defined  by  the  System  Administrator  and 
downloaded  from  the  CDM  at  start  up  time  to  the  NTH. 

The  statistics  are  kept  in  files  on  each  of  the  Test  Bed 
hosts.  This  approach  is  simple.  The  statistics  files  oan  be 
accessed  and  cleared  by  the  IISS  operator  with  proper  authority. 
The  reduction  of  the  raw  data  provided  by  the  system  statistics 
gathering  capabilities  inolude  the  following  computation: 

•  Message  type  (total  number) 

•  Message  to  a  specific  destination  (total  number) 

•  Message  from  a  specific  source  (mean,  6td  deviation) 

•  Application  Process  run  time  (mean,  std,  deviation) 

Vendor  supplied  accounting  packages  resident  on  the  various 
hosts  supplement  the  statistics  provided  by  the  Test  Bed 
Software. 

3.1.1.3.24  Data  Downloading 

Each  NTM  is  responsible  for  requesting  its 
configuration/ operational  support  data  from  the  CDM  when 
restarted.  Thus  each  NTM  sends  to  the  CDM  request  processor  a 
downloading  message  request  which  identifies  the  AP  Cluster  and 
required  information  which  is  returned  by  the  CDM. 

3. 1.1. 4  Network  Transaction  Manager  Functional  Specifications 

The  functional  specifications  implied  by  the  scenarios 
presented  in  Section  3. 1.1. 3  are  identified  and  are  presented  in 
this  Section. 
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3. 1.1. 4.1  Update  NTH  Table  (Future) 

Mission:  To  initiate  and  to  implement  the  downloading,  as 

required,  of  CDM  data  needed  to  support  the 
operation  of  the  HTM. 

Functional  Specifications: 

1.  Formulate  request  for  MTM  data  by  transmitting  a 
message  to  the  CDM  Request  Prooessor.  The  message 
uniquely  identifies  the  originating  MTM. 

2.  Receive  the  HTM  data  transmitted  by  the  CDM. 

3.  Check  the  MTM  data  transmitted  by  the  CDM. 

4.  Initialize  the  MTM  tables  and  store  MTM  data  received 
from  the  CDM. 

5.  Detect  non-respon6e  from  CDM  request  prooessor. 

6.  Log  error  in  Test  Bed  error  file. 

7.  Report  completion  of  download  operation  and  status  to 
host  IISS  operator  station. 

3. 1.1. 4. 2  Receive  and  Interpret  Message 

Mission:  To  receive  and  to  interpret  messages  sent  to  the  MTM  by 
the  Application  Processes  or  by  the  COMM  Subsystem. 

Functional  Specifications: 

1.  To  name  uniquely  the  mall  boxes  to  be  used  in 
communicating  with  one  specific  instance  of  an 
Application  Process 

2.  To  detect  when  a  mail  box  has  been  written  into 

3.  To  read  the  message  contained  in  the  mail  box 

4.  To  provide  any  acknowledgement,  if  required,  to  the 
transmitting  process 

5.  To  remove  the  header  of  the  message,  if  required 
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6.  To  identify  the  nature  of  the  message 

7.  To  route  to  its  proper  destination 

8.  To  detect  Application  Prooess  message  initiation 
requirement 

9.  To  detect  Application  Prooess  completion  message 

10.  Above  functions  are  implemented  by  making  use  of  the 
communication  primitives  described  in  8ection  8.1.5 

S. 1.1. 4. 8  Authorise  Message  (Future) 

Mission:  To  enforce  the  legal  souroe/legal  destination 

constraints  declared  for  the  MTM  messages,  and  to 
report  exceptions. 

Functional  Specifications: 

1.  To  enforce  the  legal  souroe  constraints  associated  with 
a  given  AP  Cluster 


Figure  8-20.  Guaranteed  Delivery 
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2.  To  enforce  the  legal  destination  constraints  associated 
with  an  AP  Cluster 

3.  Legal  source  and  legal  destination  constraints  are 
defined  in  the  CDH  by  the  System  Administrator.  The 
legal  source  and  legal  destination  constraints  are 
defined  on  an  Application  Process  basis. 

4.  To  log  violation  of  the  legal  destination  and  source 
constraint  on  the  error  log 

5.  To  notify  the  transaitter  Application  Process  of  legal 
destination  constraint  violations 

6.  To  obtain  legal  source  and  legal  destination 
constraints 

7.  To  allow  the  definition  of  AP  Cluster  authorization 
privileges,  as  well  as  authorization  by  specific 
Application  Processes. 

Exaaple:  MCMM,  *  :  All  MCMM 
Exaaple:  MCMM.  26:  Only  MCMM  26 

3. 1.1. 4. 4  Coaplete  Message  Header 

Mission:  To  foraulate  and  to  append  the  proper  NTM  header  to  a 
aessage  transmitted  to  the  HTM  for  processing. 

Functional  Specifications: 


I 


1.  To  obtain  all  the  inforaation  from  the  source 
Application  Process.  For  exaaple: 

•  Message  type 

•  Destination  (logical) 

•  Delivery  trigger 

•  Message  length 

•  Data  type  (ASCI I /EBCDIC  or  (BINARY) 
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2.  To  obtain  all  the  predefined  information  supplied  for 
the  message.  For  example: 

e  Logging  flag 

e  Statistics  flag 

e  Test  flag 

e  Integrity  check  flag 

e  Guaranteed  delivery 

e  Message  priority 

3.  To  create  the  following  information: 

•  Message  serial  number  (on  an  AP  Cluster  basis) 
e  Message  time  stamp  (on  a  host  basis)-only  if  logged 

4.  To  obtain  from  the  MTM  configuration: 
e  Logical  source  name 

5.  To  obtain  the  length  of  the  message  header  containing 
the  above  information 

6.  To  format  the  above  information  in  a  header  per  the 
format  specifications  described  in  Section  3.3 

7.  To  report  any  errors  to  the  source  Application  Process 

8.  To  log  any  error  in  the  Test  Bed  error  file 
3. 1.1. 4. 5  Log  Message 

Mission:  To  create  a  permanent,  user-readable  record  of  the 

messages  transiting  in  the  Test  Bed  environment.  This 
record  is  a  complete  description  (header,  data 
section)  of  the  message. 

Functional  Specifications: 

1.  To  obtain  the  message  logging  information  from: 

a.  The  message  header 
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b.  The  NTH  operational  option  data  defined  in  the  CDM. 

2.  To  log  messages  whenever  the  Message  header  flag  or  the 
CDM-def ined  log  Message  systeM  flag  is  set.  (Future  - 
initially  all  Messages  are  logged) 

3.  When  appropriate,  to  log  the  inf or Mat ion  (header,  data) 
contained  in  the  Message 

4.  The  record  is  kept  in  the  Message  log  file  kept  on  each 
host 

5.  To  allow  for  the  centralized  access  of  the  Message  log 
file  by  the  IZSS  operator 

6.  To  allow  for  the  selective  clearing  of  the  file  by  the 
IISS  operator  according  to  a  procedure 

3. 1.1. 4. 6  Send  Message 

Mission:  To  route  and  transMit  Message  to  its  appropriate 
destination. 

Functional  Specifications: 

1.  To  deternine  the  physical  destination  address  of  the 
Message  froe  its  logical  destination  address 

2.  To  decide  whether  the  Message  is  to  be  routed  on  AP 
Cluster,  off  AP  Cluster,  or  off  host 

3.  To  transnit  the  Message  to  the  COMM  AP  Cluster  for  off 
host  transnission.  The  Message  is  to  be  transnitted  to 
the  appropriate  nail  box,  according  to  the  priority  of 
the  Message 

4.  To  obtain  acknowledgenent  of  receipt,  if  required 

5.  To  detect  and  report,  if  appropriate,  the  following 
error  conditions  to  the  Message  initiator: 

a.  Destination  address  is  unknown  (Mailbox  not  found) 

b.  Destination  address  is  the  initiator  itself 

c.  Destination  address  is  an  inactive  process 
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6.  To  log  the  above  error  conditions  in  the  Test  Bed  error 
file 

7.  Above  functions  are  iapleaented  by  Baking  use  of  the 
ooBBunication  primitives  described  in  Section  3.1.5 

3. 1.1. 4. 7  Interpret  Message  Type 

Mission:  To  exaaine  and  to  differentiate  between  aes sages  of 
different  types  for  the  purpose  of  providing  proper 
MTM  actions  and  responses. 

Functional  Specifications: 

1.  To  obtain  the  aessage  type  inforaation 

2.  To  recognise  all  valid  aessage  types 

3.  To  invoke  the  proper  MTM  processing  of  the  inooaing 
aessage 

4.  To  detect  and  report  undefined  aessage  types 

3. 1.1. 4. 8  Initiate  Application  Process 

Mission:  To  request  the  local  host  operating  systea  to  load  and 
to  execute  a  given  Application  Prooess. 

Functional  Specifications: 

1.  To  apply  the  following  scheduling  rules  to  select  the 
Application  Processes  to  be  initiated: 

•  Selection  based  on  absolute  tiae  (Future) 

•  Priority  based  selection  rules  (Future) 

Higher  aessage  priority  first,  lower  priority 
last 

Messages  of  the  saae  priority  are  scheduled  on 
a  first  in  first  out  basis 

Lower  priority  aessages  are  aged  whenever  a 
higher  priority  aessage  is  selected  (future) 
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2.  To  formulate  a  request  to  the  local  host  operating 
system  to  load  and  execute  the  Application  Process 
described  in  the  message  extracted  from  the  message 
queues 

3.  To  create,  to  name,  new  mailboxes 

4.  To  maintain  the  higher  and  lower  message  priority 
queues.  Maintenance  functions  include: 

e  Removal  without  omission  or  duplication  of  messages 
that  have  been  dispatched 

•  Detection  of  overflow 

•  Reporting  of  errors  in  queue  management 

5.  To  obtain  status  information  from  the  host  operating 
system 

6.  To  maintain  the  list  of  active  application  processes 

7.  To  report  the  failure  of  initiating  an  Application 
Process  to  the  requestor,  if  appropriate,  and  to  log 
the  failure,  with  appropriate  error  description  in  the 
Test  Bed  error  file 

8.  To  record  the  Application  Process  identification  and 
time  of  day  in  the  Application  Process  Activity  Log 
(start  time)  (Future  -  Activity  Log). 

3. 1.1. 4. 9  Terminate  Application  Process 

Mission:  (1)  to  perform  the  housekeeping  operations  associated 

with  the  normal  termination  of  an  Application  Process, 
and  (2)  to  perform  the  error  notification  and 
housekeeping  operations  associated  with  the  abnormal 
termination  of  an  Application  Process. 

Functional  Specifications: 

1.  To  detect  the  termination  of  an  Application  Process 

2.  To  recognize  normal  and  abnormal  termination  conditions 
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3.  In  the  event  of  normal  termination: 

a.  To  record  the  Application  completion  time  in  the 
Application  Process  Activity  Log  (Future) 

b.  To  clear  any  mail  boxes  used  to  communicate  with 
the  Application  Process  just  terminated 

c.  To  notify  the  requestor  of  the  termination  (if 
required) 

d.  To  maintain  the  list  of  active  application 
processes 

4.  In  the  event  of  abnormal  termination: 

a.  To  record  the  Application  termination  time  in  the 
Application  Process  Activity  Log  (Future) 

b.  To  obtain  the  termination  code  or  6tatus  from  the 
local  operating  system 

c.  To  generate  the  appropriate  Test  Bed  error  code 
equivalent  to  the  local  operating  system  abnormal 
termination  code 

d.  To  notify  the  requestor  of  the  abnormal  termination 
condition,  if  required. 

e.  To  clear  any  mail  boxes  used  to  communicate  with 
the  Application  Process  just  terminated 

f.  To  initiate  the  termination  of  any  offspring 
Application  Processes  of  the  Application  Process 
(Future) 

g.  To  update  the  directory  of  active  Application 
Processes  by  deleting  the  Application  Process  just 
terminated 

h.  To  update  the  directory  of  offspring  Application 
Process  by  deleting  the  offspring  Application 
Processes  identified  in  Step  f 
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3.1.1.4.10  Exception  Handling 

Mission:  (1)  to  gain  knowledge  of  exception  calls  placed  by  any 

on  AP  Cluster,  Application  Subsystems  and  Test  Bed 
System  Services;  and  (2)  to  log  and  notify  requestors 
of  such  calls. 

Functional  Specifications: 

1.  To  keep  informed  of  all  exception  calls  to  the  local 
operating  system  generated  from  within  the  AP  Cluster 

2.  To  obtain  the  error  status  code  associated  with  the 
exception  call  and  the  identification  of  the  offending 
Application  Process 

3.  To  map  the  local  operating  system  error  codes  into 
equivalent  Test  Bed  error  codes 

4.  To  record  occurrence  of  errors  and  identification  of 
offending  Application  Processes  into  Test  Bed  error 
file 

5.  To  notify  the  requestor/ initiator  of  the  Application 
Process  of  the  error  status  as  appropriate. 

3.1.1.4.11  Communication  with  Application  Process 

Mission:  To  accept  messages  and  to  deliver  messages  to  the 
Application  Process. 

Functional  Specifications: 

The  above  mission  is  accomplished  by  making  use  of  the  Send 

message  and  Receive  message  functional  capabilities  described  in 

Sections  3. 1.1. 4. 6  and  3. 1.1. 4. 2. 

3.1.1.4.12  Message  Pairing 

Mission:  To  match  message  pairs  (question/answer)  and  to  report 
open  pairs  at  the  end  of  tine  out  period. 

Functional  Specifications: 

1.  To  recognise  messages  requesting  pairing  services 

2.  To  extract  the  identity  of  the  expected  messages  in 
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reply  to  the  message  requesting  pairing  processing 

5.  To  initiate  a  watch  dog  timer  upon  receipt  of  the 
pairing  processing  request  message.  The  source 
defining  the  time  out  period  (CDM  or  message,  or  system 
default)  and  the  duration  of  the  time  out.  (Release  2.0 
implementation  is  "system  default") 

4.  To  close  the  pair  when  the  expected  message  is  received 
and  to  disable  the  watch  dog  timer 

5.  In  the  event  of  a  time  out,  to  notify  the  Application 
Process  who  initiated  the  message  requesting  pairing 
processing 

6.  To  reoord  the  ooourrence  of  the  time  out  in  the  Test 
Red  error  file.  The  reoord  identifies: 


e 


3.1.1.4.13 


Mission: 


The  Requesting  Application  Process 

The  message  type  and/or  serial  number  requesting 
pairing  processing 

The  tine  of  day 

The  destination  Application  Process 
Error  Logging 

(1)  to  log  the  occurrence  of  an  error  with  sufficient 
information  to  identify: 


•  The  nature  of  the  error 

•  The  offending  process 

•  The  end  user  of  the  prooess 

•  The  time  of  day  of  the  error 

and  (2)  to  gain  access  to  the  log  from  a  central 
looation  ( IISS  operator)  with  an  authorised  procedure 

Functional  Specifications: 


1.  To  maintain  an  error  logging  file  on  each  Test  Bed  host 
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2.  To  allow  access  to  this  file  by  an  authorised  user 

3.  To  support  the  chronological  ordering  of  the  error  file 
obtained  by  concatenating  the  local  error  files 
maintained  on  each  host  (Future) 


4.  To  allow  the  clearing  of  the  error  file  under  control 
of  an  authorised  user  with  an  authorised  procedure 


5.  To  log  the  following  information  for  each  error: 
•  Nature  of  the  error  in  Test  Bed  error  codes 


•  Unique  identification  of  the  offending  process 

•  End  user  of  the  offending  process 

•  Time  of  day  of  the  error 


3.1.1.4.14  Message  Integrity  Checking 

Mission:  (l)  to  detect  messages  which  have:  (a)  improperly 
formulated  headers,  (b)  improperly  formulated  data 
sections  (Future);  and  (2)  to  report  and  log  such 
conditions. 


Functional  Specifications: 

1.  To  allow  header  integrity  checking  control  via  NTM 
operating  options  defined  in  the  CDM.  (Future:  Rel  2.0 
-  options  defined  in  NTM) 

2.  To  allow  data  integrity  checking  control  via  NTM 
operating  options  defined  in  the  CDM  (Future).  In  the 
early  implementation.  Application  Processes  are 
responsible  for  message  data  integrity  checking. 

3.  To  support  header  and  data  integrity  checking  control 
at  the  NTM  and  system  level. 

4.  To  support  data  integrity  checking  control  on  a  message 
basis.  (Future)  In  the  follow-on  implementation,  this 
service  is  provided  if  either: 

a.  Data  integrity  checking  is  requested  in  the  message 
header 
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b.  Or  if  data  integrity  checking  is  requested  at  the 
system  level  via  information  provided  by  the  MTM. 

Data  integrity  checking  may,  in  addition,  be  specified 
to  be  performed  by  the  MTM  or  by  the  Application 
Process . 

5.  To  perform,  when  requested,  the  following  message 
header  integrity  checks: 

e  Editing  of  each  field 

•  Self  consistency  of  the  following  user  defined 
fields: 

Message  type 

Destination 

Del ivery  trigger 

Data  type 

6.  To  perform,  when  requested  via  CDM  flag,  the  following 
message  data  section  integrity  checks:  (Future) 

•  Number  of  data  fields 

•  Editing  of  each  field 

•  Range  checking  of  each  data  element 

The  data  used  to  support  the  above  checks  is  defined  in 
the  CDM  and  downloaded  to  the  NTM  tables  on  start  up. 

The  CDM  definitions  recognize: 

•  Integer  notation 

•  Floating  point  notation 

•  String  notation  (n  characters) 

•  Undefined  range 

•  Upper,  lower  range  limits 
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•  Domains 

7 .  To  report  the  occurrence  of  errors  to  the  message 
initiator  via  predefined  Test  Bed  error  codes 

8.  To  log  the  occurrence  of  the  error  in  the  Test  Bed 
error  file.  The  record  includes: 

•  Message  type 

•  Message  serial  number 

•  Message  initiator 

•  Error  code 

•  Time  of  day 

9.  To  prevent  the  propagation  of  an  erroneous  message 
through  the  Test  Bed 

3.1.1.4.15  Resource  Osage  Statistics 

Mission:  To  gather  the  following  Resource  Usage  Statistics: 

•  Usage  frequency 

•  Processing  time 

•  Message  frequency 

•  Process  response  time 
Functional  Specification: 

1.  For  each  message,  to  gather  the  following  information 
at  the  sender  and  receiver  AP  Cluster: 

•  Message  type 

•  Message  serial  number 

•  Message  time  stamp 

2.  For  each  Application  Process,  to  gather  the  following 
information  on  the  Application  Process  AP  Cluster: 
(Future  -  Application  Process  logging  files  are  not  in 
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the  Release  2.0  implementation) 

•  Application  Process  name 

•  Start  time 

•  Completion  time 

•  Above  information  is  gathered  if  it  is  available 

3.  To  log  the  above  information  in  files  maintained 
locally  (message  logging  file  and  Application  Process 
logging  file  (Future)) 

4.  To  support  the  querying  and  concatenation  of  the 
message  logging  files  and  Application  Process  logging 
files  from  a  central  location  (Future). 


5.  To  clear  the  message  logging  and  the  Application 
Process  logging  files  by  an  authorised  user 

6.  To  compute  the  following  statistics  from  the 
concatenated  message  and  Application  Prooess  logging 
files:  (Future  -  The  raw  data  is  collected  but  not 
processed  to  obtain  this  information  in  Release  2.0) 


•  Message  frequency  by  message  type 

•  Application  prooess  usage  frequency  by  application 
process  type 

•  Application  process  processing  time  (mean,  6td  dev) 
by  application  process  name  and  for  all  application 
processes 

•  Application  process  response  time  (mean,  std  dev) 
by  application  process  name  and  for  all  application 
processes 


3.1.1.4.16  Guaranteed  Delivery 


Mission:  To  guarantee  selectively  the  delivery  of  messages  to 
Application  Processes. 


Functional  Specification: 

1  To  provide  the  following  guaranteed  delivery  services 
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to  messages  requesting  this  service 

2.  To  acknowledge  the  receipt  of  a  guaranteed  delivery 
Message  to  the  initiating  Application  Prooess  or  to  the 
NTH  forwarding  such  a  Message. 

3.  To  initiate  the  delivery  of  such  a  Message  to  its  next 
delivery  point  until  an  aoknow 1 edgeaen t  is  received 
froa  the  delivery  point  (ITM  or  ApplicationProcess) 

Attempts  to  deliver  the  Message  are  Initiated  when 
either  one  of  the  following  occurs: 

•  Message  is  first  received 

•  Target  AP  Cluster  is  restarted 

•  Target  Application  Prooess  is  initiated 

4.  To  notify  the  II8S  operator  in  the  event  of  failure  to 
deliver  the  guaranteed  delivery  Message.  Pailure  to 
deliver  such  a  Message  is  recognised  when  the  age  of 
the  Message  exceeds  the  age  liait  set  for  the  AP 
Cluster.  In  the  event  of  delivery  failure,  the 
following  inforaation  is  provided  to  the  I IBS  operator: 
(Future  -  Release  2.0  is  a  Manual  prooess  to  review 
Message  files) 

•  Tine  staap  of  Messages  (date,  tiae  of  day) 

•  Source,  destination 

•  Contents  of  Message  (header,  data  section) 

5.  To  record  guaranteed  delivery  failures  in  a  special  log 
on  the  host  where  the  failure  was  detected 


3.1.1.4.17  Svstes  Status  Broadcast 


Mission:  To  broadcast  systea  status  inforaation  to  all  IISS 

users.  The  IISS  operator  initiates  the  broadcast  and 
supplies  the  text  of  the  Message  to  be  broadcasted. 


Functional  Specification: 


1 . 


Systea  service  which  allows  the  broadcast  to  all 
terminals 
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2.  Service  can  be  invoked  by: 

a.  IISS  operator 

b.  Privileged  progress 

S.  Operator  or  privileged  program  supplies  text  of 
broadcast 

5. 1.1. 4. 18  IISS  Start  Up 

Mission:  To  start  up  IISS  Software  Services  on  a  Test  Bed  Most. 
Start  up  operations  are  initiated  by  the  IISS 
operator . 

Functional  Specifications: 

1.  To  accept  IISS  operator  start  commands  and  data  inputs 
from  the  IISS  operator  oonsole,  or  from  a  command  file 

2.  To  start  up  the  IZ88  Software  Servioes  required  to 
support  the  functionality  of  the  Test  Bed: 

a.  To  initiate,  in  the  proper  sequenoe,  the  IISS 
software  modules  required  to  support  the 
Application  Cluster  Configuration  assigned  to  the 
host . 

b.  To  carry  out  the  start  up  soenario  for  the  specific 
host  application  cluster  conf iguration  (loading  of 
operational  option  data,  dialogs  with  other  hosts, 
etc. ) . 

3.  To  report  the  completion  (or  any  error  message)  of  the 
XI8S  Software  8ervioes  start  up  to  the  IISS  operator. 

3.1.1.4.19  IISS  Shutdown 

Mission:  To  shutdown  the  IISS  Software  Servioes  running  or 
dormant  on  a  Test  Bed  host.  Shutdown  operation  is 
initiated  by  the  IISS  operator. 
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Functional  Specifications: 

1.  To  accept  IISS  operator  shutdown  couands  either  from: 

a.  The  host  IISS  Operator  Console,  or 

b.  A  shutdown  message  transnit ted  by  the  NTM 

2.  To  broadcast  shutdown  messages  to  all  IISS  terminals 
at  a  frequency  prescribed  by  the  IISS  operator 

3.  To  monitor  processes  still  active  at  the  end  of  the 
shutdown  countdown  period  and  to  report  the  identities 
of  these  processes  to  the  IISS  operator 

4.  To  terminate,  under  the  direct  control  of  the  IISS 
operator,  those  processes  found  active  at  the  end  of 
the  shutdown  period 

5.  To  save  all  pertinent  Information  required  for  the 
restart  of  the  Test  Bed  without  omission  or 
duplication  of  application  processes  and  without  the 
loss  of  concurrency  between  the  databases,  journals, 
and  application  prooess  request  queues.  (Future) 

6.  To  terminate  all  IISS  Software  Services  in  the  proper 
sequence 

7.  To  report  the  completion  of  the  shutdown  operations  to 
the  IISS  operator 

3.1.1.4.20  IISS  Restart 


Mission:  1)  To  restart  the  IISS  Software  Services  on  a  given 

Test  Bed  host;  2)  To  achieve  synchronization  with 
other  Test  Bed  Application  Processes  and  to  maintain 
database  concurrency.  Restart  is  initiated  by  the 
IISS  Operator. 

Functional  Specifications: 

1.  To  accept  IISS  operator  restart  commands  and  data 
inputs  from  the  IISS  Operator  Console  or  from  a 
Command  file 

2.  To  startup  the  IISS  Software  Services  required  to 
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support  the  functionality  of  the  Test  Bed 

a.  To  initiate,  in  the  proper  sequenoe,  the  IISS 
Software  aodules  required  to  support  the  host 
Application  Cluster  Configuration. 

b.  To  carry  out  the  startup  scenario  for  the  specific 
host  Application  Cluster  configuration 

c.  To  aohieve  synchronisation  of  all  Application 
Process  request  queues  in  the  IISS  systea,  without 
oaission  or  duplication  of  application  processes 
(Future  -  request  queues  are  not  saved  during 
shutdown) 

d.  To  aaintain  concurrency  of  the  on  host  databases 
with  the  other  databases  integrated  in  the  Te6t 
Bed 

3.  To  report  the  ooapletion  Cor  any  error  aessage)  of  the 
restart  of  the  IISS  Software  Services  to  the  IISS 
operator 

3.1.1.4.21  IISS  Recovery  (Future) 

Mission:  To  perfora  the  recovery  of  the  IISS  databases. 

Journals,  and  application  process  request  queues, 
without  oaission  or  duplication.  The  IISS  recovery  is 
initiated  by  the  IISS  operator. 

Functional  Requireaents : 

1.  To  ensure  that  Recovery  processing  is  equivalent  to 
noraal  processing 

2.  To  accept  Recovery  initiation  coaaands  and  other 
reoovery  input  data  fron  the  IISS  operator 

3.  To  be  able  to  roll  back,  roll  forward  to  and  fron  an 
IISS  operator  designated  checkpoint 

4.  To  re-apply  the  streaa  of  application  processes 
subnitted  during  noraal  processing  without  oaission  or 
dupl i cat ion 

5.  To  allow  the  exclusion,  under  IISS  operator  control, 
of  one  or  several  application  prooess  types  froa  the 


SDS620 1 40000 
1  November  1985 


stream  of  application  processes  submitted  to  recover 
the  databases 

6.  To  maintain  concurrency  between  application  process 
queues,  database  journals,  and  the  databases 
integrated  in  the  Test  Bed 

7.  To  suspend  normal  processing  while  performing  the 
reoovery  operations 

8.  To  notify  the  IISS  operator  of  the  completion  (or  any 
error  messages)  of  the  recovery  operation 

3.1.2  Common  Data  Model  Configuration  Item 

3. 1.2.1  CDM  Mission  Statement 

The  Common  Data  Model  serves  two  purposes  in  the 
implementation  of  the  Test  Bed. 

First.  The  CDM  is  a  repository  of  system  information.  This 
information  is  used  at  compile  time  or  at  run  time.  The 
information  contained  in  the  CDM  is  used  to  support  all 
operational  phases  of  the  Test  Bed  life  cycle:  maintenance, 
application  development  and  operation. 

Second,  the  CDM  allows  application  processes  to  query 
Common  Data  distributed  among  the  Test  Bed  databases  without 
regard  to  its  location  and  format. 

3. 1.2. 2  CDM  Functional  Areas 

The  configuration  tree  of  the  CDM  is  shown  on  Figure  3-21, 
which  shows  three  major  functional  areas: 

•  CDM  Maintenance 

•  Application  Development 

•  CDM  Request  Processor 

3. 1.2. 2.1  CDM  Maintenance  Functions 

The  CDM  Operational  Scenarios  presented  here  are  introduced 
for  the  sole  purpose  of  supporting  the  identification  of  the 
functional  specifications  to  be  met  by  the  CDM  processor.  These 
scenarios  are  not  meant  to  imply  a  specific  implementation  of 
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these  functional  specifications.  Consequently,  the  final  design 
of  the  CDM  processor  nay  implement  scenarios  whioh  differ  from 
the  scenarios  presented  here. 

S. 1.2. 2. 1.1  Operational  Scenarios 

The  description  of  the  Coaaon  Data,  that  is  the  Coaaon  Data 
Model  and  the  systea  data,  aust  be  entered,  edited  and 
retrieved. 

The  CDM  Maintenance  Operations  referenced  above  are 
perforaed  by  the  CDM  Adainistrator .  These  operations  are 
represented  on  the  attached  XDKFO  diagram  entitled  "Operate 
Common  Data  Model",  node  A1  (Figures  8-22,  3-28,  3-24,  and  3-25 
for  the  IDKFO  diagrams) . 

The  following  narrative  supports  the  discussion  of  the 
"Maintain  CDM  Data"  node.  With  respect  to  this  node,  one  can 
draw  the  following  renarks: 

1.  A  scheaa  of  the  CDM  aust  first  be  built  in  order  to 
retrieve,  store  and  edit  any  CDM  inforaation. 

2.  To  ensure  a  self  consistent  CDM.  the  relationship  of 
any  update  to  the  CDM  entity  or  attribute  definition 
aust  be  checked .  A  alniaua  level  of  checking  includes 
uniqueness  oheoklng.  The  sheer  amount  and  the 
diversity  of  the  data  lteas  to  be  stored  in  the  CDM 
allitate  for  oonputer  assisted  oheoklng. 

3.  Any  update  to  the  CDM  takes  plaoe  once  the  checks 
listed  above  have  been  perforaed  and  did  not  reveal 
any  errors. 

4.  The  data  dictionary  relationships  supported  by  the  CDM 
are  automatically  updated  as  part  of  the  update 
function. 

5.  The  version  number  of  the  CDM  is  likewise 
automatically  aaintalned.  To  be  useful,  the  CDM 
version  nuabering  systea  aust  be  of  sufficient 
granularity  to  avoid  reooapi lation  of  application 
processes  unaffected  by  a  ohange  in  the  CDM  data. 
(Future) 
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3. 1.2. 2. 1.2  CDM  Maintenance  Functional  Specifications 

The  CDM  Maintenance  functions  are  performed  by  the  CDM 
Maintenance  utilities  to  create,  revise  and  expand  the  CDM  data. 

The  CDM  Maintenance  utilities  perforn  the  following 
functions: 

1.  Access  Control:  Access  oontrol  to  all  CDM  Maintenance 
functions  are  performed  under  strict  access  oontrol . 
Access  oontrol  is  enforced  via  password  and  user  nane. 

2.  CDM  Data  Aooess:  The  following  data  Manipulation 
functions  are  provided: 

e  CDM  Data  Entry  Functions 

e  CDM  Data  Update  Functions 

e  CDM  Data  Edit  Functions 


Figure  3-21.  CDM  -  Configuration  Tree 
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•  CDM  Data  Selective  Retrieval  Functions 
e  CDM  Data  Reporting  Function 

e  CDM  Data  Delete  Function 

The  above  functions  are  applicable  on  all  CDM  data. 

CDM  Data  Definition:  The  above  data  entry  functions 
are  used  to  define  all  data  known  to  the  CDM.  The  data 
known  to  the  CDM  Includes: 

e  CDM  Sohema 

e  Application  External  Schemas 
e  Test  Bed  Conceptual  Schema 
e  Integrated  databases  Internal  Schemas 
e  Mappings  Existing  Between  the  Above  Schemas 
e  Domain  Information 
e  Range  Information 

e  Retwork  Resources  (looation  of  AP  Clusters, 
databases,  configuration)  (Future) 

e  Test  Bed  Security  Information  (Future) 

e  User  Interface  Support  Information  (Future) 

e  Virtual  Terminal /Real  Terminal  Mappings  (Future) 

e  Error  Messages  (Future) 

•  Message  Format  Definition  (Future) 

•  Application  Process  description  (single  instanoe, 
queue  driven. . . . )  (Future) 

CDM  Data  Checking:  The  following  CDM  data  cheoking 
functions  are  provided: 

e  Uniqueness  of  relation  names  at  the  conceptual  level 
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Figure  3-24.  AO  -  Operate  CDM  Functions 


Maintain  COM  Data  Function* 
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•  Uniqueness  of  entity  names  at  the  conceptual  level 

•  Uniqueness  of  attribute  use  class  names  at  the 
conceptual  level 

•  Uniqueness  of  key  class  names  at  the  conceptual 
level 

5.  CDM  Data  Dictionary:  The  following  data  dictionary 
functions  are  provided: 

•  Index  of  Conceptual  Entities 

•  Index  of  External  Entities 

•  Index  of  Internal  Entities 

•  Cross  Reference  of  External  Entities  and  Application 
Processes 

•  Glossary  defining  the  various  entities,  attributes, 

relationship 

6.  CDM  Version  Number:  A  CDM  data  version  numbering 
scheme  is  provided.  This  scheme  maintains 
automatically  the  version  number  of  the  information 
used  by  an  Application  Process  and  the  version  number 
of  the  CDM  data  used  to  compile  the  Application 
Process.  Version  number  identifies  CDM  data  changes 
that  require  recompilation  of  Test  Bed  Application 
Processes  and  downloading  of  CDM  data.  (Future) 

7.  CDM  Integration  Methodology  Utilities  The  declaration 
and  checking  of  Extended  IDEF1  constraints  are 
supported . 


8.  CDM  database  Recovery  and  Concurrency  Control 

The  recovery  of  the  CDM  database  is  supported  via  the 
recovery  mechanisms  provided  by  the  CDM  database 
manager  (ORACLE). 


3. 1.2. 2. 1.3  Implementation  Steps 


To  reduce  development  cost  and  to  meet  the  deve i opmmr 
schedule,  the  CDM  Maintenance  functions  are  implemented  < 
stepwise  fashion. 
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Step  1  is  implemented  by  making  use  of  the  maintenance 
utilities  provided  by  the  database  Manager  supporting  the  CDM . 
The  ORACLE  Relational  database  Manager  has  been  selected  for  the 
CDM.  As  part  of  its  standard  utilities,  ORACLE  provides: 

•  Aooess  Control 

e  Access  from  a  VAX  Native  Terminal 
e  Data  Entry 

Step  2  would  include  all  other  functions  not  included  in 
Step  1.  The  following  list  applies  to  the  ORACLE 
implementation: 

e  Access  to  Maintenance  Utilities  from  an  IISS  Terminal 

e  Access  through  the  NDML  to  the  CDM  data 

e  Forms  assisted  maintenance  of  the  CDM 

3. 1.2. 2. 2  Application  Prooess  Development 

3. 1.2. 2. 2.1  Operational  Scenario 

The  development  steps  of  an  integrated  Application  Process 
are  portrayed  in  the  IDEFO  diagram  shown  on  Figures  3-26  and 
3-27. 


With  reference  to  this  diagram,  the  major  steps  of  the 
development  of  an  integrated  Application  Processes  are: 

1.  Establish  Data  Requirements  of  Application  Process 

Based  on  the  data  requirements  of  the  user,  the  CDM 
establishes  an  External  Sohema  suitable  to  support  the 
application  process  contemplated.  If  all  entities  and 
attributes  required  by  the  application  process  already 
exist  in  the  Conceptual  Schema,  this  operation  reduces 
to  formulating  an  External  Schema  which  is  a  subset  of 
the  Conceptual  Schema.  Otherwise,  the  new  entities 
required  by  the  new  Application  Prooess  under 
development  must  first  be  added  and  integrated  in  the 
Conceptual  Schema,  and  reflected  in  appropriate 
Internal  Schemas . 
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From  an  operational  viewpoint,  the  definition  of  the 
External  Scheaa  and  any  addition  to  the  existing 
Conceptual  Soheaa  are  perforaed  by  the  CDM 
Adainistrator  (for  data  security  reasons).  The  CDM 
Administrator  uses  the  Test  Bed  Reutral  Data  Definition 
Language  to  define  the  required  soheaas. 

Once  the  External  Scheaa  has  been  developed  by  the  CDM 
Adainistrator,  a  report  of  the  External  Scheaa  is  then 
obtained  and  coaaunicated  to  the  Application  Developer 
(application  prograaaer). 

For  data  security  reasons,  however,  the  External  Scheaa 
is  referenced  by  naiae  in  the  Application  Process  and  is 
directly  obtained  by  the  Precoapiler  froa  the  CDM. 

This  approach  guarantees  tight  data  security,  since  the 
Application  prograaaer  cannot  aodify  the  soheaa  and 
hence  his  data  access  privileges,  without  explioit 
action  froa  the  CDM  Adainistrator.  The  printout  of  the 
External  Soheaa  oonveys  the  inforaation  required  by  the 
Application  Developer  to  write  the  integrated 
Application  Process. 

2.  Generate  Code  of  Application  Process 

2a.  Integrated  Applications  (Class  II  Environaent) 

Based  on  the  user  requirements  and  on  the  External 
Scheaa  developed;  the  Integrated  Application  Developer 
designs  and  codes  the  required  Application  Process.  In 
the  Test  Bed,  the  Application  Process  is  either  a  COBOL 
or  Fortran  program  which  queries  data  distributed 
across  the  Test  Bed  databases  as  if  the  data  was 
contained  in  a  single  database  bound  to  the 
Application.  All  data  queries  are  formulated  via  the 
Test  Bed  Reutral  Data  Manipulation  Language.  The  I/O 
operations  are  performed  via  Test  Bed  supported  I/O 
services.  User  interaction  is  facilitated  by  the  Test 
Bed  provided  User  Interface.  This  interface  supports 
forms  management,  data  checking  and  menu  handling 
capabilities.  The  Application  programmer  references 
the  user  interface  services  via  procedure  calls. 

2b.  Existing  Applications 

Existing  Applications  need  to  be  brought  under  the 
control  of  the  NTM  to  be  under  the  control  of  the  IISS 
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user.  This  is  done  by  making  existing  applications 
cone  under  the  control  of  the  Test  Bed  known  to  the 
CDM.  This  definition  information  is  used  to  update  the 
relevant  MTM  tables,  and  permits  the  XISS  user  to  cause 
the  execution  or  the  cancellation  of  existing 
applications  from  the  XX88  user  terminal.  Existing 
Applications,  in  general,  perform  Input /Output 
operations  to  the  user  terminal  and  to  the  database  and 
files  supporting  them.  Database  and  file  I/O 
operations  of  existing  applications  are.  in  general, 
satisfactory  to  the  1X88  user  and  do  not  need  to  be 
disturbed  when  the  application  is  brought  under  the 
control  of  the  the  Test  Bed. 

On  the  other  hand,  the  terminal  I/O  operations  need  to 
be  redirected  via  the  MTM  to  take  place  the  IISS  user 
terminal.  The  redirection  of  terminal  I/O's  can  be 
accomplished  either  by: 

1.  Modifying  the  I/O  statements  contained  in  the  existing 
Application  Process  Code  so  as  to  perform  the 
nondatabase  I/O  via  the  VTM  and  UI  services  provided 
by  the  Test  Bed  (Send  Message,  Receive  Message,  Output 
Screens,  etc.),  or 

2.  Modifying  some  to  the  system  I/O  routines  that  are 
linked  with  existing  applications  so  as  to  effectively 
redirect  the  I/O  operations  to  the  KTM.  This 
approaoh,  which  works  well  on  some  machines  (e.g.,  IBM 
CICS)  and  does  not  require  customized  modifications  of 
each  application,  is  not,  however,  possible  on  all 
machines . 

5.  Precompile  Code  of  Application  Process 

3a.  Isolate  and  Replace  NDML  Statements 

The  above  development  steps  result  in  a  COBOL  or 
Fortran  program  which  implements  the  logic  of  the 
intended  Application  Prooes6.  The  program  thus 
written  is  not  however  compilable  by  the  host  provided 
COBOL  or  Fortran  compiler.  The  reasons  for  this  are 
that  the  program  contains: 

e  A  reference  to  an  external  schema  specified  in  the 
Test  Bed  HDDL  not  recognized  by  the  host. 

e  NDML  statements  which  are  not  recognized  either  by 
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the  COBOL  or  Fortran  compiler  or  by  any  of  the 
host  supported  database  managers. 

Thus,  the  integrated  application  programs  must  be 
precompiled  to  remedy  the  above  problems.  The  precompiler  will, 
in  addition,  transform  the  NDML  statements  into  procedures  which 
can  be  executed  by  the  database  managers  integrated  by  the  Test 
Bed.  The  problems  associated  with  the  aggregation  and  data 
transforms  pertaining  to  the  distributed  environment  are  also 
resolved  by  the  precompiler. 

In  the  6201M  implementation  of  the  Test  Bed,  the 
precompiler  is  resident  on  the  VAX  and  is  bound  to  the  CDM 
database  manager.  In  the  same  environment,  all  queries  are 
precompiled  by  the  VAX  precompiler  and  distributed  to  the  host 
for  final  compilation.  The  IISS  system  oonoepts  and  design 
allow  these  functions  to  be  performed  on  the  Honeywell  or  on  the 
IBM  computers. 

Per  the  above  scenario,  the  Test  Bed  precompiler  generates 
the  following  classes  of  output: 


1.  Precompiled  application  process  code 

2.  Single  node  query  processors  (COBOL  code) 

3.  Data  aggregators  (tables) 

4.  Query  stager /scheduler  (tables) 

5.  Conceptual  to  external  transformers  (COBOL  code) 

6.  Error  message 

The  precompilation  process  is  shown  in  Figure  3-27,  and  the 
interaction  of  the  precompiler  with  its  environment  is 
shown  in  Figure  3-28.  The  precompiled  application  process 
code  is  now  a  COBOL  or  Fortran  Program  in  compilable 
format,  where  the  NDML  statements  have  been  suppressed  and 
replaoed  by  procedures  which  initiate  messages  to  the 
corresponding  6ingle  node  query  processors  and  data 
aggregators . 

Once  successfully  precompiled,  the  precompiled  application 
process  source  code  files  are  sent  to  their  respective 
hosts  for  compilation.  These  transmissions  take  place  via 
the  Network  Transaction  Manager. 
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5b.  Foraulate  Single  Mode  MDML  Query 

The  single  node  query  processors  are  COBOL  procedures 
which  query  data  froa  a  single  database.  As  such, 
these  procedures  contain  data  nanipulation  stateaents 
which  are  specific  to  the  target  database  aanager6. 
Also,  the  query  processors  are  tailored  to  the  target 
data  structure. 

The  steps  required  to  generate  the  single  node  query 
processors  are  these: 

e  The  aulti  node  conceptual  MDML  query  i6  deooaposed 
into  a  set  of  single  database  MDML  query  processors. 

e  The  resulting  aulti  node  conceptual  MDML  query  is 
analysed  and  an  optiaising  deooapos it ion/aggregation 
strategy  is  foraulated.  The  strategy  ref leots  the 
storage  characteristics  of  the  distributed  databases 
as  expressed  by  the  Internal  Soheaas  or  rather  their 
conceptual  equivalent. 

e  The  aulti  node  conceptual  MDML  query  is  deooaposed 
into  a  set  of  single  database  MDML  query  processors. 

5c.  Generate  Query  Processor 

•  For  each  single  database  MDML  query  processor,  an 
internal  scheaa  access  path  is  deteralned.  The 
access  path  reflects  the  data  structuring 
characteristics  of  the  database  holding  the  data. 
This  inforaation  is  derived  froa  the  internal  scheaa 
of  the  database. 

e  A  COBOL  procedure  based  on  the  access  path 

deteralned  above  is  then  autonatically  generated. 
This  procedure  is  non-database  aanager 
specif ic( although  it  reflects  the  data  structure  of 
a  specific  database)  and  as  such  contains  generic 
GODASYL  data  aanipulation  stateaents. 

•  In  addition  to  the  logic  required  to  carry  out  the 
data  retrieval  operations,  the  query  processors 
contain  the  logic  required  to  transforn  the  data 
retrieved  froa  the  internal  foraat  and  units  to  the 
foraat  and  units  prescribed  by  the  Conceptual 
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Schema.  The  transformation  to  the  conceptual  format 
and  units  allow  performance  of  data  integrity  checks 
prior  to  aggregation  as  well  as  simplifying  the 
declaration  of  the  data  integrity  checking  support 
information. 

•  Once  the  generic  query  processor  has  been  generated, 
the  generic  CODAS YL  data  manipulation  languages  are 
replaced  by  the  specific  data  manipulation 
statements  recognised  by  the  target  database 
manager. 

Specify  Data  Aggregation  Step 

The  query  aggregators  perform  the  Join  and  Project 
Operations  required  to  assemble  the  data  specified  by 
the  distributed  query.  These  join  and  project 
operations  are  specified  at  preoompile  time  by  the 
precompiler.  The  join  operation  allows  assembly  of 
data  contained  in  two  relations  sharing  a  common 
attribute  on  a  tuple  by  tuple  basis,  whereas  the 
projection  operator  allows  discarding  of  attributes  not 
relevant  to  the  query  at  hand. 

The  query  graph  which  reflects  the  strategy  required  to 
fulfill  the  distributed  query  assigns  the  nature, 
sequence  and  location  of  the  operations  performed  by 
the  various  aggregators. 

The  data  aggregators  aggregate  data  presented  to  them 
in  conceptual  format  and  units.  Likewise,  aggregators 
present  data  to  other  aggregators  in  the  same  format . 
However,  the  last  aggregator  routes  the  aggregated  data 
to  the  conceptual  to  external  transformer.  This  module 
performs  the  format  and  unit  transformations  required 
to  return  data  in  external  conceptual  formats  and  units 
to  the  querying  Application  Process. 

The  data  aggregators  aggregate  data  supplied  by  two 
different  data  sources.  These  sources  may  either  be 
another  data  aggregator  or  a  query  processor. 

Specify  Query  Scheduling 

The  query  scheduler  controls  the  processing  of  a 
distributed  query  through  scheduling  and  staging 
instructions  specified  by  the  precompiler.  The  control 
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functions  performed  by  the  query  scheduler  include: 

•  Monitoring  the  status  of  the  various  query 
processors ,  data  aggregators ,  and  conceptual  to 
external  transformer  involved  in  the  distributed 
query  processing. 

•  Scheduling  of  the  data  aggregation  operations  to 
minimize  the  transmission  time  (main  controllable 
component  of  cost  of  a  distributed  query). 

The  scheduling  of  the  data  aggregators  is  performed 
dynamically,  at  run  time,  by  the  query  scheduler. 

The  query  scheduler  uses  actual  data  byte  counts 
supplied  by  the  query  processors  and  data  aggregators 
to  decide  on  the  location  of  the  next  level  of  the  data 
aggregation  operations.  Figure  3-29  illustrates  the 
control  and  data  flow  originated  and  received  by  the 
query  scheduler. 

The  query  scheduler  has  the  following  responsibilities: 

•  Request  initiation  of  the  query  processors 

•  Request  initiation  of  the  data  aggregators 

•  Request  initiation  of  the  conceptual /external 
transformer 

•  Dynamic  selection  of  the  data  aggregation  sequence 

•  Monitoring  of  status  messages  sent  by  the  data 
aggregators  and  query  processors 

•  Signalling  to  the  application  process  (status,  data) 

The  implementation  of  the  query  processors  assumes  that 
the  query  processors  do  not  receive  any  intermediate 
results  from  data  aggregators  or  other  query 
processors.  This  simplification  allows  the  parallel 
initiation  of  all  query  processors. 

Distribute  and  Install  Modules 

Once  the  query  processors  have  been  generated,  they 
must  be  distributed  to  their  respective  hosts. 
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compiled,  assembled  and  linked. 

The  compilation,  assembly  and  linking  steps  are 
performed  by  the  compiler,  assembler  and  linker  of  the 
respective  host  where  the  module  (query  processor  or 
data  aggregator)  is  to  run. 

The  source  code  for  the  modules  are  transmitted  from 
the  VAX  to  the  target  host  via  the  Network  Transaction 
Manager.  The  operational  data  controlling  the  data 
aggregators  is  distributed,  at  run  time,  via  the  MTM. 

3. 1.2. 2. 2. 2  Functional  Specification 

The  development  of  integrated  Application  Processes  via  the 
above  scenario  implies: 

1.  A  schema  integration  methodology  to  setup  the  Common 
Data  Model 

2.  A  Neutral  Data  Definition  Language  to  declare  Common 
Data  Resources  in  an  Integrated  Application  Process 

3.  A  Neutral  Data  Manipulation  Language  to  retrieve  data 
contained  in  heterogeneous  databases 

4.  A  precompiler  to  substitute  the  Neutral  Data 
Manipulation  Language  statements  with  a  set  of 
cooperating  procedures  performing  the  data  retrieval 
operations  specified 

The  zunctional  specifications  of  each  of  the  above  building 
blocks  required  to  develop  integrated  Application  Processes  are 
as  follows: 

1.  Schema  Integration  Methodology 

A  methodology  is  required  to  define  external  and 
conceptual  schemas  in  a  flexible  and  unambiguous 
fashion. 

The  methodology  to  be  developed  focuses  on: 

•  Degree  of  normalisation  required  to  build  a 

conceptual  schema  that  earn  be  expanded/contracted 
with  minimum  impact  on  existing  schemas  (external, 
conceptual,  and  internal). 
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•  Guidelines  for  the  efficient  integration  of  existing 
databases . 

•  Mappings  between  external ,  conceptual ,  and  internal 
schemas . 

2.  Neutral  Data  Definition  Language 

A  Neutral  Data  Definition  Language  (NDDL)  is  provided 
by  the  Test  Bed.  Neutral  refers  to  the  non-database 
specific  aspect  of  the  data  definition  language 
provided  by  the  Test  Bed.  The  Test  Bed  NDDL  is  used  to 
describe  the  various  schemas  of  the  integrated  Test  Bed 
databases . 


i 

i 
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The  Test  Bed  NDDL  thus  must  support  the  definition  of: 

•  External  schemas 

•  Conceptual  schemas 

•  Internal  schemas 

•  The  mappings  existing  between  the  schemas  listed 
above 

•  Relational  schemas 

•  Network  schemas 


h 


Entities  or  relations 

Attributes  in  a  relation  or  in  a  record 
Domain  definitions  compatible  with  COBOL 
Attribute  ranges  (numeric.  Boolean) 

External  schema  name 

Hierarchical  schema  (or  future  enhancements) 
Attribute  unit  atnd  format  representation 
Derived  attributes 
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External  schemas  are  referenced  by  application 
processes.  The  external  schema  is  not  physically 
distributed,  it  is  kept  in  the  CDM  and  is  referenced  by 
the  application  prooess.  This  reference  is  used  by  the 
Test  Bed  precompiler  at  compile  time. 

3.  Beutral  Data  Manipulation  Language 

A  Meutral  Data  Manipulation  Language  (MDML)  is  provided 
by  the  Test  Bed.  The  MDML  is  used  to  query  the  data 
contained  in  the  databases  integrated  by  the  Test  Bed. 

The  Test  Bed  MDML  functional  specifications  are: 

•  To  be  a  relational  oriented  language 

•  To  be  compatible  with  COBOL 

•  To  be  non  procedural 

•  Each  statement  is  delimited  by  easily  recognizable 
characters 

•  To  support  the  retrieval  of  a  set  of  tuples 

•  To  use  variables  definition  compatible  with  COBOL 

•  To  return  a  status  code  (completion,  error)  upon 
execution 

•  To  support  queries  embedded  in  a  COBOL  program 

•  To  support  retrieval  queries  qualified  by  the 
following  predicates: 

Equal 

Mot  equal 

Greater  than 

-  Greater  or  equal 

Less  than  or  equal 

Less  than 
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-  Boolean  operator  AND 

*  -  Boolean  operation  HOT  (FUTURE) 

e  To  support  retrieval  from  one  or  more  relations 

e  To  support  at  least  retrieval  queries  constrained  by 
at  least  4  level  of  qualifiers 

e  To  support  restriction  (selection)  operations 

e  To  support  natural  and  equal  join  operations 

e  To  support  projection  operations 

e  Hot  to  cause  a  locking  of  the  database  when  querying 
data 

e  To  use  variable  definitions  compatible  with  FORTRAN 

e  To  support  requests  embedded  in  a  FORTRAN  program 

e  To  support  update  requests  embedded  in  a  COBOL 
program 

e  To  support  insertion  of  a  single  tuple 

e  To  support  modification  of  a  set  of  tuples 

•  To  support  the  deletion  of  a  set  of  tuples 

The  initial  implementation  of  the  6201  NDML  is  not 
intended  to  support  distributed  data  updates.  However, 
the  NDML  syntax  and  implementation  shall  include  update 
commands . 

4.  Application  Process  Precompiler 

The  Test  Bed  Precompiler  performs  the  following 
,  functions: 

4a.  Prepass  of  COBOL  Application  Process  Code 

e  Prepass  COBOL  74  Source  Code 

•  Recognise  invoked  external  schema  by  names. 
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•  Recognize  all  NDML  statements  and  replace  these 
statements  by  equivalent  comment  statements 

•  For  each  NDML  statement: 

-  Assign  a  unique  number  to  the  query  scheduler 

Insert  a  procedure  call  to  the  uniquely 
identified  query  stager/ scheduler  controlling  the 
execution 

Establish  work  area  to  receive  the  data  in  a 
COBOL  compatible  fashion 

4b.  Formulate  Single  Database  Query 

•  Obtain  external  schema  from  CDM 

•  Transform  external  NDML  query  into  conceptual  NDML 
query 

•  Formulate  query  decomposition  based  on  data  location 

•  Decompose  NDML  conceptual  query  into  NDML  conceptual 
single  database  query 

•  For  each  subquery: 

Assign  unique  number  to  the  subquery 

Generate  query  processor 

4c.  Generate  Query  Processor 

To  generate  the  single  database  query  processors 
implied  by  one  NDML  query,  the  precompiler  needs  to 
perform  the  following  functions: 

•  Formulate  access  path 

•  Generate  code  for  query  processor  or  generate 
equivalent  tables  to  perform  required  data 
retrievals 

•  Insert  internal  schema  -  if  required 

•  Insert  data  format  operations 
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•  Insert  data  to  perform  data  integrity  checks 

•  Insert  code  to  generate  byte  counts  for  retrieved 
infornation 

•  Insert  code  to  transmit  retrieved  information  byte 
count  and  retrieval  status  to  the  query  scheduler 

•  Insert  code  to  store  retrieved  data  into  a 
designated  file 

•  Specify  the  format  of  the  data  handed  to  the  query 
processor 

e  Use  standard  error  messages  and  status  information 

•  Generate  status  oode  (error,  completion)  upon 
execution 

In  the  6201M  implementation,  the  query  processors  are 

restricted  to  target  the  following  database  managers: 

•  IDS  II  on  Honeywell  Level  6,  operating  under  GCOS 
MOD400  V03  (Limited  Tests) 

•  IDMS  on  IBM  3081  under  MVS 

•  I DBMS  on  VAX  for  IDSS  AP  Cluster  (IDSS  2.0)  (Not 
Tested) 

•  VAX- 11  DBMS 

•  ORACLE  on  VAX  for  the  CDM  AP  Cluster 

•  TOTAL  on  IBM 

•  IMS  on  IBM  (Limited  Tests) 

•  ISAM  or  VSAM  (Future) 

e  Other  database  management  systems  (Example  DB2) 

4d.  Specify  Data  Aggregation  Step 

To  specify  the  data  aggregation  step,  the  precompiler 

performs  the  following  functions: 
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•  Formulate  aggregation  operations  to  be  performed 
(equal  join,  not  equal  join,  semi-join  (future),  and 
union) 

•  Provide  data  aggregator  operational  information  to 
the  data  aggregator 

e  Specify  the  format  of  the  data  supplied  by  the  query 
processors 

The  data  aggregators  use  the  data  supplied  by  the 

precompiler  to  perform  the  following  functions: 

•  Formulate  aggregation  operations  to  be  performed 
(equal  join,  not  equal  join,  semi -join  (future),  and 
union) 

•  Obtain  required  internal  schemas  to  create  work  area 
to  receive  and  process  data 

•  Provide  error  signaling  logic  (using  standard  error 
messages) 

•  Obtain,  aggregate  and  output  data  supplied  by  query 
processors 

•  Generate  the  byte  count  of  the  aggregated  data  and 
report  the  byte  count  and  status  information  to  the 
query  scheduler. 

•  Accept  format  of  data  supplied  by  the  query 
processors 


•  Generate  status  code  (error,  completion)  upon 
execution 

4e.  Specify  Query  Scheduling 

To  specify  the  query  scheduling  step,  the  precompiler 
performs  the  following  functions: 

•  Determine  the  possible  data  aggregation  sequence  and 
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location 

•  Invoke  the  query  scheduler  from  the  Application 
Prooess 

The  query  scheduler  uses  the  data  supplied  by  the 
precompiler  to  perform  the  following  functions: 

e  Request  initiation  of  query  processors 

e  Request  initiation  of  data  aggregators 

•  Request  initiation  of  conceptual /external 
transformer 

e  Select  dynamically  and  oontrol  the  data  aggregation 
sequenoe 

e  Request  tlae  out  service  froa  the  RTM 

e  Request  the  cancellation  of  all  query  processors, 
data  aggregators,  conceptual /external  transformer, 
related  to  a  given  distributed  query,  in  the  event 
of  errors 

e  Receive,  interpret  and  report  error  messages 

received  froa  the  query  processors,  data  aggregators 
and  oonoeptual /external  transformer 

4f.  Generate  Conceptual  External  Transformer 

To  generate  the  Conceptual -to-External  Transformer,  the 
precoapiler  performs  the  following  functions: 

•  Obtain  the  oonoeptual -to-external  unit 
transformation  froa  the  CDM 

•  Obtain  the  conceptual -to-external  format  conversions 
froa  the  CDM 

•  Invoke  the  conceptual -to-external  transformer  froa 
the  Query  Scheduler 

The  Conceptual -to-External  Transformer  uses  the  data 
supplied  by  the  precompiler  to  perform  the  following 
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functions : 

•  Carry  out  the  conceptual -to-external  unit 
transformations 

e  Carry  out  the  conceptual -to-external  format 
conversion 

e  Report  errors  to  the  query  scheduler 

4g.  Precompiler  Characteristics  and  Constraints 

e  Precompiler  is  portable 

e  Precompiler  is  written  in  COBOL  74 

e  Precompiler  is  designed  to  allow  extension  to  other 
non-COBOL  high  order  languages 

•  Precompiler  Initial  implementation  is  the  VAX.  uses 
DHL  of  CDM  database  manager  and  is  controlled  from 
native  terminal 

e  Precompiler  issues  error  messages  when  required 

e  Precompiler  can  be  invoked  by  the  NTM  and  make  use 
of  the  RDML 

•  Precompiler  is  structured  to  support  ad-hoc  query 
processing 

5.1.3  The  User  Interface  Configuration  Item 
3. 1.3.1  Pser  Interface  Mission  Statement 

The  IISS  system  requirement  document  identifies  a  need  to 
provide  users  with  an  overall  view  of  the  system  as  an 
integrated  application  rather  than  as  a  collection  of  disjointed 
programs.  Users  need  to  be  able  to  invoke  the  various  Test  Bed 
subsystems  such  as  MCMM,  MRP  and  IDSS  from  a  single  terminal  in 
a  consistent  manner  even  though  the  applications  may  reside  on  a 
number  of  different  computer  systems. 

Additionally,  the  User  Interface  should  support  the 
development  of  "User  Friendly"  application  programs  that  are 
flexible  and  maintainable. 
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3. 1.3. 2  Pser  Interface  Functional  Areas 

The  function  of  the  Test  Bed  User  Interface  is  two  fold. 
First,  the  PI  provides  an  environment  that  not  only  allows  but 
encourages  good  user  interface  design.  Secondly,  the  PI 
provides  a  run  time  environment  that  supports  interactive 
dialogue.  These  two  subsystems  are  called  the  Pser  Interface 
Development  System  and  the  Pser  Interface  Management  System.  The 
various  functional  areas  making  up  the  PIDS  and  PIMS  are  shown 
on  the  Pser  Interface  Configuration  Tree  given  in 
Figure  3-30. 

Figure  3-30  shows  two  major  functional  areas: 

•  Pser  Interface  Development  System  (PIDS) 

•  Pser  Interface  Management  System  (PIMS) 

The  PIDS  is  a  set  of  tools  that  assist  application 
developers  with  forms  maintenance,  report  writing  and  rapid 
application  generation.  These  tool6  are  available  to  the  user 
as  part  of  the  PIMS. 

The  Pser  Interface  is  a  forms  based  system.  This  means 
that  all  communication  between  an  application  program  and  the 
user  is  done  through  electronic  forms  on  a  video  terminal 
screen.  Electronic  forms  are  full  screen  template  displays  that 
act  as  prompts  or  memory  joggers  to  users  as  they  fill  in  input 
data  i terns . 

The  PIDS  provides  two  facilities  for  editing  forms: 

•  The  forms  can  be  edited  using  a  language  called  the 
Forms  Definition  Language  which  is  compiled  with  the 
Forms  Language  Compiler. 

•  The  forms  can  be  edited  through  the  use  of  an 
interactive  application  that  prompts  the  user  for  form 
characteristics  and  allows  for  freestyle  form  layout. 

The  PIDS  Report  Writer  and  Application  Generator  are  based 
on  extensions  to  the  Forms  Definition  Language  for  program 
generation . 

The  PIMS  is  the  run  time  PI.  It  performs  the  functions 
which  are  interactive.  As  such,  the  PIMS  interfaces  with  the 
user  through  an  interface  to  the  Virtual  Terminal  or  neutral 
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User  Interface 


User  Interface  Management  System 
i  l 

i  i 

i  + - + —  User  Interface  Services 

i  i 

i  + —  Form  Processor 

i  i 

i  + —  Virtual  Terminal 

i  i 

i  + —  Application  Interface 


—  Forms  Language 
I  Compiler 

4- 
I 

+ —  Forms  Driven 
Form  Editor 
i 

i  4- —  Report  Writer 

i  l 

4- —  Application  Generator  — 4- 
i  I 

i  4- —  Rapid  Application 

i  Generator 

i 

4- —  Text  Editor 


Figure  3-30.  User  Interface  Configuration  Tree 

Test  Bed  terminal.  The  UIMS  interfaces  with  application 
programs  through  the  Application  Interface  to  the  Form  Processor 
which  handles  screen  processing  commands.  The  Application 
Interface  is  bound  to  the  Application  Process  and  contains  the 
necessary  functions  to  extract  data  from  a  form  sent  to  it,  to 
fill  out  a  form,  and  to  initiate  messages  to  the  Form  Processor 
as  well  as  receive  messages  from  the  Form  Processor. 

Figure  3-31  illustrates  the  above  concepts.  This  figure 
shows  that  the  transactions  exchanged  between  the  Form  Processor 
and  the  Application  Interface  are  handled  by  the  NTH.  A 
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description  of  the  NTH  itself  can  be  found  in  section  5.1.1  of 
this  System  Design  Specification. 

5. 1.3. 3  User  Interface  Operational  Soenerlos 

The  User  Interface  Operational  Scenarios  presented  here  are 
introduced  for  the  sole  purpose  of  supporting  the  identification 
of  the  functional  specifications  to  be  net  by  the  User 
Interface.  These  scenarios  are  not  meant  to  imply  a  specific 
implementation  of  the  functional  specifications.  Consequently, 
the  final  design  may  Implement  scenarios  which  differ  from  the 
scenarios  in  this  section. 


Figure  3-31.  User  Interface  Management  System 
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The  Test  Bed  User  Interface  supports  the  following  modes  of 
operat i on : 

•  Forms  Mode 

•  Form  Editing  Mode 

•  Application  Generation  Mode 

In  the  following  sections  is  a  description  of  these  three 
(3)  modes  of  operation. 

3. 1.3. 3.1  Forms  Mode  Operational  Scenario 

The  forms  mode  allows  the  displaying  of  predefined  forms 
for  the  purpose  of  requesting  data  from  the  user  or  for  the 
purpose  of  presenting  data  to  the  user. 

Thus,  forms  can  be  used  to  display  data,  to  input  data  or 
to  control  the  execution  of  Application  Processes  on  the  Test 
Bed. 

The  forms  which  are  displayed  have  been  predefined  and 
catalogued  on  the  CDM.  Each  form  can  be  uniquely  retrieved  by 
its  name  or  ID. 

The  following  definitions  are  convenient  when  discussing 
the  Test  Bed  forms  mode  of  operations. 

•  A  Form  is  viewed  as  a  template  defining  fields  and  their 
attributes.  The  strength  of  the  Test  Bed  forms 
processor  is  derived  from  the  single  and  shared 
definition  of  all  fields  and  variables  referenced  by 
forms.  The  forms  are  defined  in  the  Common  Data  Model - 

( Future ) 

•  Form  data  are  the  actual  values  contained  in  the  fields 
of  the  form.  These  values  may  either  be  input 
interactively  by  the  user  or  may  be  supplied  by  the 
Application  Process  as  output  data.  The  Test  Bed  forms 
processing  uses  the  attribute  definitions  available  from 
the  Common  Data  Model  to  perform  data  integrity  checking 
at  the  level  of  the  User  Interface.  This  approach 
offers  the  following  advantages: 

1.  Errors  are  detected  at  the  data  entry  point,  where 
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they  aay  be  corrected 

2.  Errors  are  not  propagated  through  the  systen 

3.  Data  integrity  checking  is  consistent 
transparent  to  the  application 

e  A  fori  instance  is  a  filled  out  form,  that  is  the 
collection  of  a  form  and  a  single  set  of  fora  data. 

This  definition  can  take  two  different  representations; 
when  viewed  by  the  user  a  fora  instance  is  defined  as 
above,  when  viewed  by  an  Application  Process  a  fora 
instance  reduces  to  fora  control  data,  fora  data,  and 
fora  naae.  The  foraat  of  the  data  is  available  to  the 
Fora  Processor. 

Displaying  a  Fora  To  Be  Filled  Out 

Consider  Figure  3-32.  A  fora  to  be  used  for  user  input  is 
placed  on  the  list  of  foras  to  be  displayed  (Display  List;.  The 
fora  to  be  displayed  is  referenced  by  its  fora  naae.  Frequently 
used  foras  aay  be  downloaded  froa  the  CDM  at  start  up  tiae  and 
placed  on  the  list  of  open  fora6  (Open  List).  Less  frequently 
used  foras  are  requested  on  an  ad-hoc  basis  froa  the  CDM.  An 
error  code  i6  generated  and  routed  to  the  Application  Process 
when  a  requested  fora  cannot  be  found. 

Filling  Out  a  Fora 

Consider  Figure  3-33.  The  fora  to  be  filled  out  is 
presented  on  the  IISS  terainal .  The  user  fills  out  the  fora,  to 
the  best  of  his  abilities.  In  doing  so.  the  user  aay  perforn 
soae  local  editing  procedures  to  correct  typos  or  other  errors. 
Typos  are  corrected  by  invoking  the  special  function  keys 
(backspace,  etc.)  defined  and  supported  by  the  host  terainal 
driver.  When  the  fora  is  filled  out  to  the  satisfaction  of  the 
user,  the  ENTER  key  is  depressed  on  the  terainal.  This  causes 
the  data  integrity  checks  to  be  perforaed. 

Invoking  the  Help  Facility 

When  filling  out  a  fora,  the  user  aay  invoke  the  Help 
Facility.  Help  aay  be  a  nessage  or  an  entire  fora.  After 
invoking  the  Help  Facility,  the  user  aay  return  to  the  original 
fora . 
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Figure  3-32.  Display/Retrieve  a  Fora 
View  of  Forms  (FUTURE) 

Form  views  allow  customization  of  forms.  A  view  is  a  form 
whose  fields  map  to  those  of  another  form  (the  base  form).  If  a 
field  is  changed  on  the  view  it  is  also  changed  on  the  base  form 
and  vice  versa.  However,  the  attributes  of  the  view  override 
those  of  the  base  form.  This  allows  the  view  to  have  different 
initial  values. 
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Figure  3-33 .  Filling  out  a  Fora  -  User  Viewpoint 


Transacting  a  Fora 

Upon  coapleting  the  filling  out  of  a  fora,  the  user 
indicates  his  willingness  to  transait  a  fora  by  depressing  a 
function  key.  This  action  causes  the  data  integrity  checks  to 
be  perforaed  unless  the  function  key  depressed  indicates  that 
the  user  would  prefer  to  quit  processing  the  fora.  The  data 
integrity  checks  are  supported  by  the  data  contained  in  the  fora 
itself.  This  approach  elininates  the  need  for  additional  CDM 
acoess.  Error  aessages  are  issued  to  the  user  when  appropriate. 
Only  error  free  foras  are  transacted,  thus  keeping  network 
traffic  to  a  ainiaua.  The  Test  Bed  is  a  aessage  driven  systea. 
Data  is  transacted  froa  the  User  Interface  to  the  Application 
by  aeans  of  a  aessage. 

Outputting  a  Fora  Instance 

Data  generated  by  an  Application  Process  aay  be  output  as 
fora  data  associated  with  a  fora.  This  fora  instance  is 
displayed  at  the  request  of  the  Application  Process.  When  the 
user  has  viewed  the  data,  he  aay  signal  his  willingness  to  view 
aore  data  by  entering  a  (next  fora)  control  character.  This 
action  allows  aore  data  to  be  displayed  on  the  terainal . 
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Outputting  a  Fora  To  Be  Filled  Outfron  an  Application 


The  Application  Process  which  has  needs  for  input  data  nay 
sake  its  needs  visible  to  the  user  by  requesting  that  a  form  be 
displayed  and  filled  out  by  the  user.  The  specific  Application 
Process  issues  a  "display  form"  command  for  that  purpose.  The 
"display  form"  command  oontains  the  name  of  the  fora  to  be 
displayed. 


Controlling  the  User  Interface 


The  User  Interface  assumes  one  of  three  major  states 


e  ACCEPT  USER  DATA 


e  ACCEPT  APPLICATION  DATA 


e  PROCESS  FORMS 


The  PROCESS  FORM  state  itself  is  made  up  of  the 
following  states: 


-  DISPLAT  FORM 


-  ACCEPT  USER  DATA 


-  INTEGRITY  CHECKING 


-  INITIATE  MESSAGE 


These  states  are  shown  on  Figure  3-54. 


Process 


Form 


Accept 
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Upon  cold  start  or  restart,  after  completing  the  startup 
procedure,  the  User  Interface  enters  the  ACCEPT  USER  DATA  state 
and  awaits  user  input.  The  PROCESS  FORM  state  is  entered 
whenever  a  command  requesting  form  processing  is  received  from 
the  user  or  from  the  Application  Process.  Such  command 
indicates  the  number  of  the  form  to  be  displayed  or  otherwise 
processed.  Normal  exit  from  the  PROCESS  FORM  state  can  take 
three  forms : 

•  Return  to  the  ACCEPT  USER  DATA  state 

•  Return  to  the  ACCEPT  APPLICATION  DATA  state 

•  Re-entry  of  the  PROCESS  FORM  state 

This  last  eventually  allows  the  chaining  of  forms,  as  is 
encountered  in  menu  processing.  The  information  controlling 
normal  exit  from  the  PROCESS  FORM  state  is  either  contained  in 
the  form  being  processed  or  is  contained  in  the  commands  sent  to 
the  form  processor  by  the  user  or  by  the  Application  Process. 
This  approach  is  flexible  and  simple.  Abnormal  exit  from  the 
PROCESS  FORMS  and  ACCEPT  APPLICATION  DATA  must  be  accommodated. 
This  is  necessary  in  the  event  of  a  malfunction  of  an 
Application  Process  or  in  the  event  of  a  change  of  mind  from  the 
user.  Abnormal  exit  from  either  state  leads  to  the  ACCEPT  USER 
COMMAND  state,  leading  the  User  Interface  ready  to  accept  user 
inputs  and  commands.  The  exit  command  is  supplied  by  the  user 
and  acts  as  an  interrupt . 

The  Run  Time  User  Interface 

Figure  3-31  depicted  the  interaction  of  the  User  Interface 
with  an  Application  Process.  As  seen  in  that  figure,  an 
Application  Process  places  calls  to  the  User  Interface 
Application  Interface  to  which  it  is  linked.  In  return  it 
receives  data.  Requests  made  by  the  Application  Process  are 
transformed  into  messages  by  the  Application  Interface  routines. 
These  messages  are  transmitted  by  the  NTM  to  the  Form  Processor, 
which  services  the  requests  as  explained  in  the  previous 
paragraphs.  Forms  instances  or  user  data  are,  in  return, 
transmitted  as  messages  by  the  Form  Processor  over  the  NTM. 

These  messages  are  then  interpreted  by  the  Application  Interface 
and  the  data  is  extracted  in  a  form  suitable  to  the  Application 
Process.  To  reduce  network  traffic  to  a  minimum,  a  complete 
forms  instance  is  transmitted,  and  the  data  is  kept  by  the  Form 
Processor.  Thus,  subsequent  calls  by  the  Application  Process  on 
data  available  to  the  Form  Processor  can  be  answered  locally 
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without  retransmission  over  the  network. 

This  run  time  portion  of  the  User  Interface  is  called  the 
User  Interface  Management  System. 

3. 1.3. 3. 1.1  Form  Processor  Operational  Scenario 

Several  operational  scenarios  are  contemplated  for  the  Test 
Bed  Form  Processor. 

Cold  Start/Restart  Scenari o 


The  Form  Processor  is  cold  started  or  restarted  by  a  device 
driver  following  a  User  Logon  request.  The  Form  Processor  then 
is  ready  for  operation  and  displays  the  first  logon  form  and 
enters  the  "ACCEPT  USER  COMMAND/ DATA"  state.  The  above  ooncepts 
are  illustrated  on  Figure  3-35  entitled  "Fora  Processor  Start 
Up". 


ttirtw  cimmM)  j 

Oevice 

itirtw  ■■■■■■> 

Form 

USER 

,  Ih*«  UfirMtin 

Driver 

Inh  hr* 

Processor 

^  request 

Figure  3-35.  Fora  Processor  Start  Up 


User  Log  On  Scenario 

Test  Bed  User  Log  On/Log  Off  scenario  is  viewed  as  a 
particular  case  of  conducting  data  integrity  checking  on  a  form 
instance.  In  this  case,  the  form  used  is  a  log  on/log  off  form, 
and  the  fora  data  is  related  to  the  log  on/log  off  operations. 
When  processing  the  logon  fora,  the  Form  Processor  requests  CDM 
data  from  the  CDM  by  sending  a  message  requesting  the  start  up 
data  to  the  CDM  request  processor.  The  CDM  contains  the  profile 
data  for  each  user.  This  table  defines  the  password  and  roles 
that  are  valid  for  a  user-i.d.  The  table  is  created  and 
maintained  by  the  CDM  Administrator  and  is  stored  in  the  CDM. 
Failure  to  log  on  prevents  the  user  from  gaining  access  to  the 
forms  used  to  control  the  Application  Processes  and  Test  Bed 
services.  These  concepts  are  shown  on  Figure  3-36. 

3. 1.3. 3. 2  Form  Edit  Operational  Scenario 

The  forms  used  by  the  User  Interface  are  predefined  and 
stored  in  the  CDM.  These  forms  are  retrieved  and  transmitted  to 
the  Form  Processor  when  a  request  is  made  for  them  by  the 
application.  The  Form  Editor  is  used  to  define  forms  and  to 
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control  the  storage,  editing  and  deletion  of  foras  which  have 
been  already  defined.  The  Foras  Driven  Fora  Editor  makes  use  of 
foras  to  facilitate  the  definition  of  new  foras  and  to  oontrol 
aaintenance  operations  on  the  fora  database  segaent  of  the  CDM. 
Access  to  the  Fora  Editor  is  controlled,  as  is  the  case  of  any 
prograa  having  CDM  update  privileges.  The  Fora  Editor  is 
operated  by  any  application  developer  with  sufficient  authority. 

The  following  inforaation  is  required  to  define  a  new  fora: 

a.  The  naae  to  be  given  to  the  fora 

b.  The  foraat  of  the  fora 

c.  The  naaes  of  foras  used  within  the  new  fora  (if  any) 

d.  The  fields  contained  in  the  fora  which  are  coaaon  data 

With  the  above  inforaation,  the  application  developer  first 
identifies  an  existing  scheaa  or  creates  an  external  scheaa , 
using  the  Test  Bed  Heutral  Data  Definition  Language  (HDDL).  to 
reference  the  fields  to  be  defined  to  their  respective  CDM 
definitions.  This  linkage  ensures  an  error  free  and  effective 
transfer  of  the  data  constraints  associated  with  each  eleaent. 
Second,  the  application  developer  creates  a  new  fora  description 
which  is  uniquely  named ,  within  the  application.  The  new  fora 
description  contains: 

a.  The  naae  of  the  external  scheaas  to  be  referenced 
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b.  The  dimensions  of  the  form 

c.  For  each  subfora  invoked: 

•  The  name  of  the  subform 

•  The  position  (x.y)  of  the  top,  left  corner  of  the 
subform 

d.  For  each  new  field  Invoked: 

•  The  name  of  the  variable 

•  The  position  (x.yj  of  the  left  most  characters  of 
the  variable 

•  The  graphic  attributes  associated  with  the  field 

•  The  name  of  the  indirect  form  associated  with  the 
field  (help,  etc.) 

e.  For  each  textual  element  included: 

•  The  character  string  to  be  shown 

•  The  position  (x.y)  of  the  left  most  character 

•  THE  GRAPHIC  ATTRIBUTES  ASSOCIATED  WITH  THE  TEXTUAL 
field 

f.  The  name  of  the  next  fora  to  be  displayed  or  whether 
control  is  returned  to  the  ACCEPT  USER  COMMANDS  state 
or  to  the  ACCEPT  APPLICATION  COMMANDS  state  (Future) 

g.  Security  information  associated  with  the  form,  that  is, 
the  role  of  the  user  having  access  to  the  fora 

The  position  (x.y)  of  each  field  can  either  be  defined  by 
its  relative  position  or  graphically  (graphic  definition: 
future).  The  Fora  Editor  can  be  invoked  from  an  IISS  terminal. 
The  Fora  Editor  communicates  with  the  CDM  processor  via  the  NTM. 
The  CDM  processor  performs  the  CDM  updates,  edits. 

3. 1.3. 3. 3  Application  Generation  Operational  Scenario 

Application  programs  can  be  described  using  an  Application 
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Definition  Language  (ADL).  The  ADL  is  similar  in  syntax  to  the 
Forms  Definition  Language  (FDL)  and  contains  both  FDL  and 
Heutral  Data  Manipulation  (NDML).  The  ADL  can  be  compiled  to 
produce  an  application  progran  that  accesses  the  CDM  via  forms. 
Figure  5-57  describes  the  application  generation. 

A  report  program  is  a  special  kind  of  program  generated  by 
the  Application  Generator.  Paging  and  other  formatting 
characteristics  of  the  report  depend  on  the  data  to  be  displayed 
vi thin  it.  The  language  used  to  describe  reports  is  called  the 
Report  Definition  Language  (RDL)  and  the  portion  of  the 
Application  Generator  used  to  compile  the  RDL  is  called  the 
Report  Writer. 

5. 1.5. 4  Functional  Specifications 

The  functional  specifications  implied  in  the  scenarios 
presented  in  Section  5. 1.5. 3  are  identified  and  presented  in 
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3. 1.3. 4.1  User  Interface  Management  System 
Fora  Processor  Start  Up 

Mission:  To  ready  the  Fore  Processor  for  user  interaction  upon 
user  logon  to  the  VAX  host  under  an  IISS  account. 

Func t i onal  Spec 1 f i cat i ons : 

1.  To  initialise  the  Fore  Processor,  and  all  eodules 
associated  with  it. 

2.  To  initiate  a  eessage  to  the  NTM.  This  eessage 
identifies  the  Fore  Processor. 

3.  To  display  the  first  fore  to  be  displayed  on  the 
Tereinal . 

;  4.  To  place  the  Fore  Processor  in  the  "Accept  User 

Coeeand"  State 

User  Logon 

Mission:  To  ensure  that  only  authorized  users  nay  gain  access  to 
the  Test  Bed  Coeeand  fores. 

I 

I*  Functional  Specifications: 

1.  To  display  the  Test  Bed  logon  fore.  The  Test  Bed  logon 
a  fore  requests  that  the  following  data  be  supplied: 

t  •  User-i.d. 

•  User  role 

•  User  password  -  not  echoed 

12.  To  validate  the  above  information  against  access  data 

supplied  by  the  CDM 

3.  To  reject  unqualified  answers  by  repeating  step  one 

» 

!  4.  To  record  user  statistics  tor  qualified  users 

|  5.  To  display  the  first  page  of  the  Command  selection  menu 
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6.  To  place  the  Form  Processor  controller  in  the  ACCEPT 

USER  COMMAND  state 

Form  Processing 

Mission:  To  perform  the  operations  required  to  process  forms: 

•  Retrieval  of  a  predefined  form 

•  Display  of  the  form 

•  Filling  out  of  the  form  (from  the  user  point  of  view) 

•  Data  integrity  checking 

•  Help  facility 

•  Window  management 

•  Text  editing 

Functional  Specifications: 

1.  Retrieval  of  a  Predefined  Form 

a.  Accept  the  name  of  the  form  to  be  retrieved.  The 
name  of  the  form  to  be  retrieved  is  supplied  by  an 
Application  Process. 

b.  Determine  whether  or  not  a  given  form  name  is 
stored  in  the  Form  Processor  forms  table. 

c.  Retrieve  a  given  form  name  from  the  Form  Processor 
forms  table. 

d.  Query  the  CDM  to  request  the  downloading  of  a  form. 
This  capability  is  required  whenever  the  form  is 
not  available  locally.  The  form  to  be  downloaded 
is  specified  by  its  name. 

e.  Formulate  and  display  appropriate  error  messages, 
if  necessary,  on  the  terminal. 

f.  Clear  form 
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2.  Display  of  a  Predefined  Form 

a.  Display  a  Blank  Fora  -  A  fora  which  is  intended  to 
be  filled  out  by  the  user  is  first  retrieved  as 
explained  in  the  operational  scenario. 

b.  Display  of  a  Fora  Instance  -  A  fora  instance  is 
created  by  first  retrieving  the  blank  fora  as 
explained  above,  and  by  adding  to  it  the  data 
defined  by  the  user  or  by  the  Application  Process. 

3.  Filling  Out  a  Fora  by  the  User 

The  fora  to  be  filled  out  is  first  displayed  (see  Display 
of  a  Blank  Fora  -  itea  2a  above).  The  user  designates  the  field 
he  wishes  to  fill  by  positioning  the  terainal  cursor  in  the  left 
aost  character  position  of  the  field  to  be  filled.  Characters 
entered  by  the  user  are  added  sequentially  in  the  field. 

a.  Cursor  Position  Control  -  The  user  aay  fill  the 
field  in  the  sequence  he  desires.  To  start 
entering  data,  the  user  positions  the  cursor  in  the 
first  character  position  of  the  field  to  be  filled 
out.  The  following  cursor  notions  are  supported: 

•  One  space  notions  (right,  left,  top,  bottom) 

•  Tab  control 

•  Next  line 

•  Beginning  of  line 

b.  Data  Entry  -  The  user  then  types  in  the  data,  on  a 
character  basis. 

The  Form  Processor  detects  the  following 
conditions : 

•  Field  overflow 

•  Data  entry  outside  a  field 

The  Form  Processor  recognizes  a  special  character 
which  indicates  that  the  user  has  completed  the 
data  entry  operations. 
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Data  Integrity  Checking 

Once  a  fora  has  been  filled  out  by  the  user,  it  is 
checked  for  integrity.  The  following  capabilities  are 
provided: 

a.  Edit  Check  Each  Field  -  Each  field  entered  on  the 
fora  is  checked  against  the  edit  constraints 
defined  for  it  in  the  External  Scheaa  attached  with 
the  fora.  The  edit  checks  which  are  perforaed 
include: 

•  Numeric  fields 

•  Alpha  fields 

•  Predefined  nuaber  of  characters 

b.  Range  Check  Each  Field  -  Each  field  which  has 
passed  the  edit  check  is  then  checked  for  range. 
Upper  and  lower  liaits  of  each  data  itea  is  defined 
in  the  External  Scheaa  attached  with  the  fora.  The 
range  checks  which  are  perforaed  include: 

•  Upper  liait  check 

•  Lower  limit  check 

Ranges  are  not  restricted  to  be  continuous.  Range 
information  may  include  combinations  of  continuous 
and  discrete  values.  Ranges  may  be  defined  as 
tables  of  authorized  numeric  or  non-nuaeric  values. 

c.  Flag  Errors  -  The  errors  detected  by  the  edit  check 
and  range  checks  are  reported  to  the  user.  This  is 
done  by  signalling  out  the  field(s)  in  error.  The 
edit  checks  and  range  checks  are  conducted  on  the 
entire  fora  before  control  is  passed  to  the 
Application  Process. 

d.  Fora  Processor  Control  -  The  Fora  Processor  is 
controlled  as  follows: 

•  No  errors  detected  -  control  is  given  to  the 
MESSAGE  INITIATOR  state,  and  the  process  of 
initiating  a  aessage  begins 
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•  Errors  have  been  detected  -  control  is  given  to 
the  ACCEPT  USER  DATA  state  and  the  user  is  given 
the  opportunity  to  correct  his  errors. 

5.  Help  Facility 

A  help  form  is  a  form  associated  with  another  form  or  field 
which  provides  additional  information  or  explanation  of  the  data 
to  be  entered. 

a.  Invoking  the  Help  Form  -  A  means  by  which  the  user 
can  invoke  the  help  forms  associated  with  the  form 
or  with  the  given  field  within  the  form  is 
provided.  The  operational  procedure  shall,  in 
either  case,  be  similar. 

b.  Nesting  Levels  -  A  help  form  may  be  associated  with 
any  form,  even  if  it  is  a  help  form.  However,  for 
practical  considerations,  five  level  nesting  is 
considered. 

c.  Returning  to  the  Original  Form  -  A  facility  shall 
be  provided  to  enable  the  user  to  return  directly 
to  the  original  form  from  any  level  of  help, 
without  backtracking  through  the  help  forms 
invoked. 

d.  Defining  Data  on  a  Help  Form  -  Data  may  be  directly 
entered  on  the  help  form,  and  automatically  be 
inserted  on  the  original  form.  (FUTURE) 

6.  Window  Management 

Windows  are  spaces  that  are  rectangular  in  shape  that  are 
reserved  for  form  placement.  Windows  are  contained  in  forms. 
Application  Processes  and  users  manipulate  windows. 

Application  Processes  must  be  able  to  perform  the  following 
activities  at  run  time: 

a.  Add  a  form  to  a  window 

b.  Replace  a  form  in  a  window 


c.  Remove  a  form  from  a  window 
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Users  aust  be  able  to  perform  these  activities  at  run 
tiae: 

a.  Scroll  a  fora  within  a  window 

b.  Move  a  window 

c.  Shrink  a  window 
7.  Text  Editing 

Users  must  be  able  to  perform  these  text  editing  functions 
on  data  iteas: 

a.  Cut  and  paste 

b.  Global  search  and  replaoe 

c .  Repeat 

d.  Set  aargin 
Message  Initiation 

Mission:  To  initiate  the  messages  required  to: 

a.  Request  data  froa  the  CDM 

b.  Send  data  to  am  Application  Process 

c.  Send  data  to  the  Virtual  Terminal 
Functional  Specifications: 

1.  Foraulate  the  following  CDM  requests: 

•  Request  for  user  profile  data  (password,  role) 

•  Request  for  specific  fora  data 

2.  Foraulate  the  following  Application  Process  requests: 

•  Upload  of  the  fora  data,  fora  name  to  the 
Application  Process 

•  Upload  of  the  Fora  Processor  status  and  error 
conditions 
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3.  Formulate  the  following  Virtual  Terminal  requests: 

•  Request  for  user  entered  data 

•  Request  for  cursor  position 

•  Request  for  function  key  pressed  by  user 

4.  The  messages  formulated  by  the  Message  Initiator  shall 
be  in  a  well  defined  and  structured  format.  The  format 
exhibits : 

•  A  header 

•  A  data  body 

5.  Message  header  contains  the  information  required  to 
control  the  User  Interface  Management  System.  The  data 
body  contains  the  information  which  may  be  required  to 
support  processing. 

Form  Processor  Monitor 

Mission:  To  control  the  operations  of  the  Form  Processor  and  to 

coordinate  the  actions  of  the  Form  Processor  in  response  to: 

a.  User  commands 

b.  Application  Process  Commands 
Functional  Specifications: 

1.  The  Form  Processor  Monitor  allocates  control  of  the 
Process  Forms  functions  to  the  Virtual  Terminal,  or  to 
the  Application  Process. 

2.  The  Form  Processor  Monitor  allows  the  Virtual  Terminal 
to  regain  control  of  the  Form  Processor  at  anytime. 

This  is  done  on  an  interrupt  like  basis.  In  this 
event,  the  Application  Process,  if  any,  is  terminated. 

3.  The  Form  Processor  Monitor  waits  on  an  acknowledgment 
from  the  Virtual  Terminal  to  go  to  the  next  form  or 
next  state.  Standard  function  keys  are  defined  for 
that  purpose. 
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4.  The  Form  Processor  Monitor  reoognizes  a  set  of  function 
keys  (or  combination  of  keys).  These  keys  are 
consistent,  and  always  produce  the  sane  effect.  The 
following  keys  are  recognized: 

•  Quit 

•  Enter 

•  Help 

Application  Interface 

Mission:  To  facilitate  the  control  and  the  manipulation  of 
forms  and  forms  data  by  an  Application  Process. 

Functional  Specifications: 

1 .  Control  of  the  Form  Processor 

The  Application  Interface  facilitates  the  control  of 
the  Form  Processor  by  the  Application  Process.  To  that 
effect,  the  Application  Interface  offers  a  set  of 
commands  which  can  be  invoked  by  the  Application 
Process.  The  set  of  commands  supported  by  the 
Application  Interface  is  given  below: 


Remove  form 

Display  form 

Display  form 

instance 

Read  form 

Read  form  instance 

Display  error 

message 

Data  Manipulation  Primitives 

In  addition,  the  Application  Interface  allows  the 
manipulation  of  data  forms  by  the  Application  Process. 
To  that  effect,  the  Application  Interface  supports  the 
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following  data  manipulation  primitives: 

•  Read  field  value  by  najie 

•  Read  previous  value  by  name 

•  Write  field  value  by  name 

•  Query  field  attribute  by  name 

•  Set  field  attribute  by  name 

The  above  operations  are  performed  locally  by  the  Form 
Processor  which  maintains  a  local  copy  of  the  form 
instance  displayed  by  the  Virtual  Terminal. 

3.  Stored  Forms  Instance  Primitives 

Form  instances  can  be  saved  locally.  This  capability 
provides  memory  to  the  Form  Processor.  Previously 
defined  data  can  be  selectively  retained  for  further 
processing.  To  that  effect,  the  Application  Interface 
supports  the  following  stored  forms  instance 
operations : 

•  Save  form  instance  (future) 

•  Get  form  instance 

•  Delete  form  instance  (future) 

3. 1.3. 4. 2  User  Interface  Development  System 
Forms  Definition 


The  definition  of  the  forms  include  the  following  sections: 


1.  Forms  Identification 

•  Application  name 

•  Form  name 

The  system  wide  form  name  is  made  up  by  the 
concatenation  of  the  application  name  and  of  the  form 
name . 
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2.  Fora  Control  Definition 

•  Naae  of  the  help  fora  associated  with  this  fora 

•  Relative  position  of  the  fora  on  the  screen,  with 
respect  to  the  origin:  Origin  is  taken  to  be  the 
top.  left  corner  of  the  screen,  for  the  top  level 
fora.  The  location  of  the  origin  of  any  other  fora 
is  controlled  by  the  containing  fora. 

3.  Textual  Eleaent  Definition 

•  Relative  position  of  the  top  left  character  of  the 
Textual  eleaent  being  defined. 

e  Length  and  width  of  the  text  being  defined  (length 
and  width  are  ooaputed  automatically) . 

•  Display  attributes  of  the  Textual  eleaent. 

4.  Field  Definition 

•  Length  and  width  of  the  field 

•  Relative  position  of  the  field  top  left  aost 
character  with  respect  to  the  origin  of  the  fora  in 
which  the  field  is  defined. 

•  Haae  of  the  variable  to  be  stored  in  the  field. 
Variable  is  referenced  by  its  naae  as  shown  in  the 
External  Schema . 

•  Display  attributes  granted  to  the  field. 

•  Field  naae  (optional). 

5.  Field  Information  for  an  Existing  Field 

•  Set  a  field  equal  to  another  (defined)  field. 

6.  Prompt  Field 

•  Naae  of  textual  field  to  be  proapted,  or 

•  Naae  of  the  field  to  be  displayed 
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Form  Editor 


The  following  functions  are  provided  by  the  Form  Editor: 

1.  Define  Forms 

Forms  definition  is  forms  oriented.  A  form  is 
predefined  for  each  of  the  sections  of  a  form: 

•  Form  identification 

•  Form  control  information 

•  Textual  element  definition 

•  Field  definition 

•  Prompt  field  definition 

2.  Add  Field 

Fields  can  be  added  to  an  existing  form  by  using  the 
add  field  capability.  The  add  field  utility  allows  the 
definition  of  a  field  as  defined  previously. 

3.  Delete  Field 

A  field  defined  in  an  existing  form  can  be  deleted  via 
this  utility. 

4.  Set  Field  Attribute 

An  attribute  of  a  field  can  be  set  (or  reset)  by  this 
utility.  The  user  needs  to  define  the  name  of  the 
attribute  and  its  value  (Boolean,  integer). 

5 .  Save  Form 

This  utility  is  used  to  save  on  secondary  storage  (in 
the  CDM)  a  form  which  has  been  defined  by  the  user. 

6.  Get  Form 

This  utility  is  used  to  retrieve  a  form.  The  form  may 
either  be  retrieved  from  the  CDM  or  from  the  Form 
Processor  table  (if  available). 
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7.  Delete  Form 

This  utility  is  used  to  delete  a  form  stored  in  the 
CDM . 

8.  Error  Processing 

The  Form  Editor  provides  the  following  type  of  error 
processing: 

•  Check  for  uniqueness  of  names  of  forms 

•  Check  for  dimension  constraint 

•  Check  for  undefined  attribute  constraints 

The  Form  Editor  is  viewed  as  any  other  process  using 
the  forms  capability  of  the  User  Interface.  Hence,  it 
can  also  invoke  all  of  the  following  Active  Instance 
operations : 

e  Show  form 

•  Clear  fora 

•  Query  field  attribute 

•  Save  instance 

•  Get  instance 

•  Delete  instance 
Report  Writer 

Mission:  To  provide  a  means  to  translate  textual  definitions  of 
reports  into  programs  that  generate  the  reports . 

Functional  Specifications: 

1 .  Textual  Output 


The  background  template  for  the  report  is  a  form.  It 
is  specified  using  the  Form  Definition  Language. 
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2.  Database  Operations 

All  database  operations  are  described  using  the  Neutral 
Data  Manipulation  Language  (NDML)  and  are  performed  by 
the  CDMP. 

3.  Statistical  Summarization 

Simple  statistical  computations  may  be  performed  upon 
item  values  and  included  in  the  output.  The 
computations  include: 

•  Count 

•  Sum 

•  Average 

•  Minimum 

4.  Picture  Specifications 

Each  item  field  that  is  mapped  to  CDM  data  may  have  a 
picture  specified  to  define  the  output  format.  The 
editing  provided  includes  numeric  and  alphanumeric 
specification,  leading  zero  suppression,  decimal 
placement,  leading  sign  indicators,  currency  symbols, 
and  placement  of  embedded  commas. 

5.  Exceptional  Conditions 

Tests  can  be  established  for  certain  exceptional 
conditions.  An  action  or  group  of  actions  can  be 
specified  to  occur  when  the  condition  arises. 

Practical  applications  of  this  facility  include  output 
of  headers,  footers,  statistical  summaries  and  paging. 

The  fol loving  exceptional  conditions  are  recognized: 

•  Change  in  the  value  of  an  item 

•  Page  overflow 

•  Startup  of  report 
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6.  Exception  Actions 

The  following  actions  can  be  taken  when  an  exceptional 
condition  occurs: 

•  Page  ejection 

•  Change  of  fora 

•  Setting  of  a  data  itea 

•  Database  query 
Rapid  Application  Generator 

Mission:  To  provide  a  aeans  to  translate  textual  definitions  of 
interactive  database  applications  into  prograas  that  access 
databases  via  the  CDM. 

Functional  Specifications: 

1.  Application  Definition 

The  application  is  defined  by  using  an  Application 
Definition  Language  that  subsumes  the  Foras  Definition 
Language . 

2.  User  Interaction 

The  user  of  the  generated  application  nay  perfora  the 
following  activities: 

•  Filling  out  form  templates 

•  Menu  picking 

•  Itea  selection  by  cursor  position 

* 

•  Function  key  Selection 

As  a  result  of  the  user  interaction  the  following 
activities  are  performed  by  the  generated  application: 

•  Switching  between  functions 

•  Database  aodification 
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3.  Database  Operations 

All  database  operations  are  described  using  the  Neutral 
Data  Manipulation  Language  (NDML)  and  are  performed  by 
the  CDMP. 

4.  Security  and  Access  Control 

Security  and  access  control  is  provided  through  the 
mechanism  of  conditional  forms  and  triggers  sensitive 
to  particular  item  field  values.  Thus,  the 
functionality  offered  to  a  particular  user  can  be 
restricted  by  not  displaying  a  fora  containing  options 
for  certain  database  operations  or  by  not  enabling 
certain  function  keys.  Further,  other  forms  informing 
the  user  of  restrictions  on  access  can  be  displayed 
instead. 

5.  Conditional  Actions 

Conditional  actions  are  those  triggered  by  the 
occurrence  of  an  event  defined  in  an  ON  statement.  Any 
number  of  actions  can  be  triggered  by  a  single  event. 
They  involve  both  fora  processor  actions  and  database 
transactions.  It  is  primarily  the  conditional  actions 
which  determine  the  course  of  the  execution  of  the 
appl ication. 

3.1.4  The  Virtual  Terminal  Interface  Configuration  Item 

3. 1.4.1  Virtual  Terminal  Mission  Statement 

The  mission  of  the  Virtual  Terminal  Interface  is  to  afford 
terminal  independence  to  the  Application  Process  and  Test  Bed 
System  Services.  More  specifically,  the  Virtual  Terminal 
Interface  provides: 

•  Terminal  protocol  independence 

•  Terminal  character  independence 

•  Terminal  feature  independence  to  the  Test  Bed 
Applications  and  Services. 
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3. 1.4. 2  Virtual  Terminal  Functional  Areas 

The  various  functional  areas  making  up  the  Test  Bed  Virtual 
Terminal  Interface  are  shown  on  the  Virtual  Terminal  Interface 
configuration  tree  given  on  Figure  3-38. 

Figure  3-38  shows  two  major  functional  areas: 

•  Virtual  Terminal  Definition 

•  Virtual  Terminal  Implementation 
Virtual  Terminal  Definition 


The  Virtual  Terminal  defines  a  set  of  characters,  terminal 
features  and  data  exchange  protocols  which  are  considered 
standards  in  the  Test  Bed  System.  Any  Application  Subsystem  or 
Test  Bed  Service  written  specifically  for  the  Test  Bed  assumes 
that  it  is  interfaced  to  a  terminal  offering  the  character  set, 
terminal  features  and  data  exchange  protocols  defined  for  the 
Virtual  Terminal  Interface. 

Virtual  Terminal  Implementation 


The  Test  Bed  Applications  must  however  ultimately 
communicate  with  a  hardware  terminal.  It  is  the  function  of  the 
Virtual  Terminal  Interface  (VTI)  to  provide  the  necessary 
character  and  protocol  conversion  procedures.  Likewise,  the  VTI 
provides  the  mappings  that  may  be  required  to  implement  any 
Virtual  Terminal  Features  on  a  specific  hardware  terminal. 

3. 1.4. 3  Virtual  Terminal  Operational  Scenarios 

The  Virtual  Terminal  Interface  operational  scenarios 
presented  here  are  introduced  for  the  sole  purpose  of  supporting 
the  identification  of  the  functional  specifications  to  be  met  by 
the  Virtual  Terminal  Interface.  These  scenarios  are  not  meant 
to  imply  a  specific  implementation  of  the  functional 
specifications.  Consequently,  the  final  design  may  implement 
scenarios  which  differ  from  the  scenarios  shown  in  this  Section. 


3 . 1 . 4 . 3 . 1  Interface  to  a  Real  Terminal 

The  most  natural  role  for  the  Virtual  Terminal  is  to 
interface  with  a  Real  Terminal.  This  scenario  is  illustrated  on 
Figure  3-39.  This  figure  shows  the  VTI  interfacing  with  the 
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Figure  3-38.  VTI  Configuration  Tree 

hardware  terminal  through  the  terminal  driver  provided  by  the 
host  operating  system.  The  VTI  is  also  interfaced  with  the  User 
Interface  Form  Processor . 

In  this  role,  the  Virtual  Terminal  performs  the  following 
functions : 

1.  Data  Acquisition  from  the  Real  Terminal 

The  VTI  receives  data  from  the  real  terminal  according 
to  a  protocol.  This  protocol  can  either  be  character, 
line,  or  block  oriented. 
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Figure  3-39.  Interface  to  a  Real  Terminal 

2.  Data  Conversion  fron  Real  Terminal  to  VTI 

Once  the  VTI  has  acquired  data  fron  the  Terminal 
Handler,  it  nay  proceed  to  convert  the  characters 
received  into  the  VTI  character  set.  At  this  point,  it 
must  be  noted  that  character  conversion  cannot  be 
assumed  to  be  context  free.  Some  terminals  (like  the 
VIP  7200)  use  escape  sequences  which  are  several 
characters  long.  The  sequence  of  characters  indicates 
the  type  of  the  user  interrupt,  and  the  characters 
included  in  the  sequence  are  context  dependent. 

3.  Data  Transmission  to  the  User  Interface  Form  Processor 

The  VTI  data,  which  has  now  been  converted  to  the  VTI 
character  set.  with  all  terminal  dependent  character 
sequences  eliminated  is  then  transferred  to  the  User 
Interface.  This  data  transfer  is  done  on  a 
pre-negotiated  protocol  (character,  line,  block).  The 
data  is  now  punctuated  by  control  characters  taken  from 
the  set  of  VTI  control  characters.  These  control 
characters  are  used  to  indicate  the  occurence  of  things 
such  as:  line  feed,  carriage  return,  cursor  control, 
etc . 
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4.  Receiving  Data  from  the  Form  Processor 

The  Virtual  Terminal  receives  data  from  the  User 
Interface  Form  Processor  whenever  the  User  Interface 
Form  Processor  wishes  to  communicate  with  the  hardware 
terminal .  The  Virtual  Terminal  Interface  is  invoked  to 
that  effect  by  the  Form  Processor.  The  data  supplied 
by  the  Form  Processor  is,  by  definition,  in  the 
standard  Virtual  Terminal  format. 

5.  Data  Conversion  from  VTI  to  Real  Terminal 

The  data  presented  to  the  Virtual  Terminal  Interface  is 
converted  so  the  character  set  of  target  hardware 
terminal  and  the  VTI  control  characters  are  replaced  by 
the  control  characters  of  the  target  terminal .  Once 
this  conversion  has  been  completed,  the  VTI  invokes  the 
Terminal  Handler  of  the  host  operating  system.  Figure 
3-40  shows  the  mechanics  involved  in  acquiring, 
converting  and  transmitting  data  to  the  User  Interface 
Form  Processor.  This  figure  assumes  that  the  VTI  is 
not  directly  controlling  the  1/0  Terminal  Handler.  The 
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I/O  handler  is  shown  to  be  under  the  control  of  the 
host  operating  system. 

6.  Feature  Mapping 

Soae  hardware  terainals  aay  not  offer  any  hardware 
iapleaentation  support  for  all  of  the  standard  terainal 
features  assuaed  for  the  Virtual  Terainal  Interface. 

For  such  terainals,  it  aay  then  be  necessary  to 
siaulate  soae  of  the  desired  Virtual  Terainal  feature 
by  a  well  thought  out  sequence  of  operations  which  are 
iapleaentable  on  the  hardware  terainal.  This  process 
is  referred  to  as  feature  aapping. 


3. 1.4. 3. 2  Interface  to  an  Exist ins 


>lication  Progri 


Terainals  are  not  the  only  entities  in  the  Test  Bed  which 
offer  or  assuae  specific  terainal  features.  Prograas  written 
around  a  specific  terainal  hardware  exhibit  characteristics  of 
that  terainal .  Such  prograas  are  said  to  be  terainal  dependent , 
and  in  fact  are  the  general  case,  rather  than  the  exception. 

The  Virtual  Terainal  is  also  used  to  grant  to  those  existing 
prograas  the  terainal  independence  required  for  integration  in 
the  Test  Bed.  In  this  role,  the  Virtual  Terainal  perforas  all 
of  the  functions  and  services  described  in  the  previous  section 
(Section  3. 1.4. 3.1).  Refer  to  Figure  3-41.  This  figure  shows 
that  an  existing  Application  Process  invokes  the  Virtual 
Terainal  Interface  via  a  procedure  call.  Data  is  also  passed  to 
the  Virtual  Terainal  Interface.  This  data  is  stored  in  a  table, 
or  perhaps  in  a  file.  The  Virtual  Terainal  Interface  perforas 
the  necessary  conversion,  and  generates  the  equivalent  VTI  data. 
Once  the  conversion  process  is  coapleted,  the  VTI  transfers  the 
data  to  the  Network  Transaction  Manager .  Invoking  the  Virtual 
Terainal  Interface  froa  one  existing  Application  Process 
requires  that  either  one  of  the  following  nethods  be  used: 


1.  Modify  the  existing  Application  Process  and  replace  the 
I/O  statements  with  calls  to  the  Virtual  Terminal 
Interface  subroutines.  This  can  be  done  manually  or 
automatically  with  a  suitable  precompiler. 


2.  At  link  time,  replace  the  host  standard  I/O  library 
with  a  library  of  functions  including  the  Virtual 
Terminal  Interface  subroutines.  These  subroutines  have 
the  same  names  than  the  host  I/O  subroutines.  Figure 
3-41  also  describes  the  process  by  which  data  is 
transmitted  from  the  Network  Transaction  Manager  to  the 


SDS620 140000 
1  November  1985 


existing  Application  Process.  This  process  parallels 
the  process  used  to  transfer  data  from  the  existing 
Application  Process  to  the  NTH. 

3. 1.4. 3. 3  Interface  to  a  New  Application  Program 

In  this  context,  new  Application  Program  means  an 
Application  Program  specifically  written  for  the  Test  Bed.  New 
Application  Programs  are  using,  by  definition,  the  terminal 
features  offered  by  the  Virtual  Terminal  Interface.  Thus,  new 
Application  Programs  do  not  require  any  of  the  conversion 
otherwise  performed  by  the  Virtual  Terminal  Interface. 

3. 1.4. 4  Virtual  Terminal  Functional  Specifications 

The  functional  specifications  implied  in  the  scenario 
presented  in  Section  3. 1.4. 3  are  identified  and  presented  in 
this  section. 

3. 1.4. 4.1  Virtual  Terminal  Feature  Definition 

Mission:  To  provide  the  definition  of  a  set  of  common  terminal 
features  and  protocols  used  throughout  the  Test  Bed. 


Figure  3-41.  Interface  to  an  Existing  Application  Program 
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Functional  Specifications: 

The  Virtual  Terminal  Interface  definition  includes: 

1.  ASCII  character  set  (lower  case  upper  case)  as 
standard  VTI  characters 

2.  The  following  minimum  set  of  VTI  Control  characters  or 
sequences : 

•  To  indicate  the  end  of  line 

•  To  indicate  the  feeding  of  a  new  line 

•  To  position  the  cursor 

•  To  clear  the  screen 

•  To  indicate  the  end  of  a  data  block 

•  To  indicate  a  user  interrupt 

•  To  indicate  any  of  the  VTI  features  listed  below  in 
paragraph  4 

3.  The  following  minimum  set  of  VTI  features: 

•  Block  mode  display/ input 

•  Reverse  video 

•  Blinking 

•  Bold  (bright) 

•  Dim  (half-bright) 

•  Underscore 

•  Bell 

•  No  echo 

•  Upper  case 

•  Lover  case 
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•  Size  of  screen 

4.  The  following  minimum  set  of  VTI  protocols: 

•  Block  VTI /Real  Terminal 

•  Block  VTI /VTI 

3. 1.4. 4. 2  Virtual  Terminal  Implementation 

Mission:  To  implement  the  Real  Terminal /Virtual  Terminal 

protocol ,  character  set  and  feature  transformation 
required  to  achieve  terminal  independence. 

Funct i onal  Spec i f i cat i ons : 

1.  The  implementation  of  the  Virtual  Terminal  supports  the 
following  functions: 

•  Character  set  conversion 

•  Feature  mapping 

•  Protocol  conversion 

2.  The  following  real  terminals  are  used  for  demonstration 
of  the  VTI  concept : 

•  DEC  VT-100 

•  Honeywell  VIP  7200 

•  Lear  Siegler  ADM -3 

3.  An  instance  of  the  Virtual  Terminal  Interface  supports 
one  instance  of  the  real  terminal  type. 

4.  The  Virtual  Terminal  Interface  can  be  expanded  to 
include  new  features,  and  to  support  via  software 
simulation  functionality  limited  terminal  hardware. 

3.1.5  The  Communication  Subsystem  Configuration  Item 

3. 1.5.1  Communication  Subsystem  Mission  Statement 

The  Communication  Subsystem  provides  Communication  Services 
to  the  Test  Bed  Subsystems.  The  Communication  Services  allow  on 
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host  interprocess  communication  and  inter  host  communication 
between  the  various  Test  Bed  Subsystems. 

3. 1.5. 2  Communication  Subsystem  Functional  Areas 

The  configuration  tree  shown  on  Figure  3-42  identifies  the 
following  functional  areas: 

Communication  Hardwar e 


•  Local  Area  Network 

•  Wide  Area  Network 
Communication  Software 


•  Inter  Process  Communication 

•  Inter  Host  Communication 

•  Configuration  B  Maintenance 

3. 1.5. 3  Communication  Subsystem  Operational  Scenarios 

Figure  3-43  shows  the  demonstration  hardware  environment  of 
the  Test  Bed.  This  figure  shows  the  Local  Area  Network  and  the 
Wide  Area  Network  services  used  to  interconnect  the  IBM  3033 
computer  to  the  Local  Area  Network.  The  same  figure  also  shows 
the  wide  area  services  used  to  support  remote  software 
development  on  each  of  the  Test  Bed  hosts,  as  well  as  on  the 
CIDS  development  system  (CIDS  during  initial  phase  only). 

3. 1.5. 3.1  Local  Area  Network 

Refer  to  Figure  3-43.  The  Local  Area  Network  is  composed 
of  the  BUS  Interface  Units  of  the  GENET  Local  Area  Network. 

These  units  are  shown  interconnected  by  a  coaxial  cable,  with 
each  bus  interface  unit  properly  tapped  into  the  cable. 

The  Honeywell  Level  6  and  the  VAX  are  shown  to  communicate 
with  their  respective  bus  interface  units  via  two  RS-232-C 
communication  lines. 

The  IBM  3081  is  shown  to  be  connected  via  synchronous 
modems  and  a  leased  telephone  line  to  a  cluster  controller 
located  in  the  room  containing  the  Honeywell  Level  6  and  the 
VAX.  The  cluster  controller  communicates  to  a  bus  interface 
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unit  via  2  RS-232-C  lines.  A  third  RS-232-C  is  used  to  connect 
an  asynchronous  development  terminal  to  the  IBM  3081. 

The  cluster  controller  performs  the  multiplexing  and 
demultiplexing  of  the  traffic  carried  by  the  synchronous  line 
into  the  two  asynchronous  lines  shown.  In  addition,  the  cluster 
controller  also  performs  the  synchronous /asynchronous  protocol 
conversion  as  well  as  the  ASCII/EBCDIC  character  conversions. 

The  GENET  Loral  Area  Network  is  used  in  the  Permanent 
Virtual  Circuit  Mode  (PVC).  The  Local  Area  Network  supports  the 
3  Virtual  Circuits  shown  on  Figure  3-44. 

The  Virtual  Circuits  shown  on  Figure  3-44  are  permanent, 
that  is  these  circuits  are  set  up  when  the  Local  Area  Network  is 
powered  up,  and  are  maintained  until  the  system  is  shut  down. 

The  configuration  data  required  to  set  up  these  virtual  circuits 
and  to  configure  the  six  RS-232-C  ports  is  stored  in  the  GENET 
Configuration  ROM  Memory. 

Figure  3-44  shows  clearly  that  with  the  permanent  Virtual 
Circuit  approach  outlined  above,  one  RS-232-C  port  on  each 
machine  is  dedicated  to  the  bidirectional  communication 
,  operations  with  a  given  computer.  This  port/host  assignment  is 

•  known  to  the  communication  software. 

» 

P 

•  The  Local  Area  Network  described  above  clearly  allows  for 

I  the  distributed  processing  required  to  support  the  operation  of 

'  the  Test  Bed.  Each  host  is  capable  of  transferring  information 

bidirectionally  with  every  other  host.  The  approach  described 
[  here  is  used  since  no  overhead  is  incurred  to  set  up  and  tear 

!  down  Virtual  Circuits. 

3. 1.5. 3. 2  Wide  Area  Network 

Consider  Figure  3-43.  The  IBM  3081,  which  is  located  some 
three  miles  away  from  the  other  computers,  is  interfaced  to  the 
cluster  controller  via  synchronous  modems  and  a  leased  telephone 
line. 


A  line  multiplexer  allows  the  multiplexing  of  local  and 
remote  terminals  to  any  of  the  Test  Bed  hosts.  This  convenience 
is  of  major  significance  when  considering  that  software 
development  can  be  carried  out  remotely  by  the  various  ICAM 
subcontractors  having  need  to  access  the  Test  Bed.  This 
configuration  allows  SofTech ,  CDC,  PffA  and  other  ICAM 
subcontractors  to  gain  access  to  any  host  of  the  Test  Bed,  in 
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Figure  5-44.  Genet  Permanent  Virtual  Circuit 

native  node.  Likewise,  this  configuration  allows  any  remote 
terminal  to  become  an  IISS  terminal. 

The  line  multiplexer  is  also  used  to  multiplex  terminals 
located  at  SofTech  or  at  General  Electric  to  the  Central  I CAM 
Development  System  (CIDS).  This  allows  SofTech  and  General 
Electric  developer  to  6hare  a  leased  telephone  line  to  CIDS, 
located  in  Cushing,  Oklahoma  (Initial  phase). 

The  line  multiplexer  arrangement  described  above  thus 
supports  development  activities  and  forseeable  Test  Bed 
experimentation  scenarios. 

3. 1.5. 3. 3  Inter  Process  Communication  Scenario 

The  Test  Bed  software  is  composed  of  many  processes.  These 
processes  are  either  System  Services  or  Application  Processes, 
and  are  in  general  highly  independent.  Processes  which  are 
coresident  on  one  host  communicate  with  one  another  via  the 
Interprocess  Communication  (IPC)  Primitives  provided  by  the  Test 
Bed  system  software.  Processes  which  reside  on  different  Test 
Bed  hosts  communicate  with  one  another  via  the  Interhost 
Communication  (IHC)  services  provided  by  the  Test  Bed  system 
software . 
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The  following  scenario  describes  the  sequence  of  operations 
typical  of  a  communication  between  two  processes  coresident  on 
the  same  processor.  This  scenario  describes  the  communication 
activities  which  take  place  between  the  Network  Transaction 
Manager  (NTM)  and  a  typical  process  called  Process  X.  This 
scenario  is  presented  here  for  the  following  reasons: 

a.  In  the  Test  Bed.  all  communications  are  routed  via  the 
Message  Manager  portion  of  the  NTM.  This  rule  is 
convenient  since  it  allows  the  grouping  of  the  manage 
message  functions  in  one  nodule,  and  since  it  also 
allows  for  a  highly  structured  design.  The  problem  of 
supporting  communication  between  n  times  n  applications 
is  thus  reduced  to  a  much  simpler  problem,  namely  that 
of  communicating  between  any  process  and  the  NTM. 

b.  Communications  between  the  NTM  and  the  OOMM  process 
used  for  interhost  communicat ion  is  a  particular  case 
of  the  above  case.  The  simplification  encountered  in 
this  very  important  case  of  interprocess  communication 
are  pointed  out  in  the  discussion  of  interhost 
communication. 

The  following  scenario  is  implemented  when  the  NTM  on  the 
AP  Cluster  where  Process  X  resides  receives  a  message  requesting 
that  Process  X  be  initiated.  The  discussion  presented  here 
applies  to  the  initiation  of  the  first  or  any  additional 
instance  of  Process  X  on  the  AP  Cluster. 

3. 1.5. 3. 3.1  Establishing  Mail  Boxes  between  Process  X  and  the 
NTM 

a.  On  AP  Cluster  NTM  operations: 

1.  The  NTM  receives  a  message  requesting  that  an 
additional  instance  of  Process  X  be  initiated. 

2.  The  NTM  creates  a  unique  name  for  the  instance  of 
Process  X. 

3.  The  NTM  calls  upon  the  local  host  operating  system 
to  create  a  new  instance  of  Process  X. 

b.  New  Process  X  operations 

The  following  actions  are  taken  by  the  newly  created 
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instance  of  Process  X.  The  new  instance  of  Process  X  is  created 
by  the  local  host  operating  system  in  response  to  the  initiate 
Process  X  request  placed  by  the  NTH  in  Step  a. 3  above. 

1.  The  newly  created  instance  of  Process  X  obtains  the 
name  of  the  mail  boxes  it  must  use  to  communicate  with 
the  NTM  on  AP  Cluster.  The  names  of  the  mailboxes  are 
predefined  to  the  NTM  Run  Time  Routines  bound  to  the 
Process  X. 

2.  The  newly  created  instanoe  of  Process  X  creates  the 
input  mail  box  it  uses  to  obtain  data  from  the  NTM. 
This  input  mail  box  is  named  according  to  the  name 
given  to  the  AP  which  is  obtained  from  the  local 
operating  system. 

3.  The  newly  created  instance  of  Process  X  signals  to  the 
NTM  that  it  is  running  normally  and  is  ready  to  accept 
data  from  the  NTM  by  writing  into  the  NTM  input  mail 
box. 


3. 1.5. 3. 3. 2  Writing  and  Reading  into  the  Mail  Box 

a.  Writing  into  the  NTM  input  mail  box 

Consider  Figure  3-45.  Once  the  input  and  output  mail 
boxes  have  been  identified  and  created  per  the  above 
procedure.  Process  X  writes  into  the  input  mail  box  of 
the  NTM  by  invoking  the  communication  service  used  to 
write  into  a  mail  box.  The  call  is  placed  by  Process 
X,  and  the  call  conveys  to  that  communication  service 
the  following  data: 

•  Name  of  the  buffer  (in  Process  X)  which  contains  the 
data  to  be  transmitted 

•  Name  of  the  NTM  input  mail  box  to  be  written  into 
Messages  written  into  a  mail  box  are  queued  on  a 
FIFO  basis. 

The  logic  of  the  host  operating  system  or 
interprocess  primitives  prevents  overwriting  a  mail 
box  which  has  not  been  read  by  the  NTM. 

If  the  attempt  to  write  in  the  input  mail  box  was 
successful.  Process  X  continues  processing. 
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b.  Reading  the  NTM  input  nail  box 

Consider  Figure  3-45.  The  host  operating  system  (or 
IPC  primitive)  detects  the  fact  that  Process  X  wrote 
into  the  input  mail  box  of  the  NTM. 

This  allows  the  Communication  Service  for  Reading  Data 
from  input  mail  box  to  proceed  with  the  reading  of  the 
data  contained  in  the  mail  box.  This  communication 
service  also  copies  the  input  mail  box  data  into  the 
NTM  buffer . 

This  Communication  Service  also  returns  status 
information  to  the  NTM.  In  the  event  of  a  successful 
transmission,  normal  NTM  processing  continues.  In  the 
event  of  errors  in  the  transmission,  the  NTM  logs  the 
error  code  in  the  error  log  and  takes  appropriate 
action. 

3. 1.5. 3. 3. 3  Clearing  Mail  Boxes 

The  mail  boxes  created  by  Process  X  to  communicate  with  the 
NTM  must  be  cleared  when  Process  X  terminates.  Clearing  the 
mail  boxes  returns  memory  storage  to  the  buffer  pool. 

Two  eventualities  must  be  considered  when  clearing  the  mail 
boxes  used  by  Process  X  to  communicate  with  the  NTM.  The  first 
eventuality  is  the  normal  termination  of  Process  X,  and  the 
second  is  the  abnormal  termination  of  Process  X. 

3. 1.5. 3. 4  Process  Svnchronization 


Process  synchronization  capabilities  are  required  in  any 
system  made  up  of  cooperating  processes.  In  the  Test  Bed, 
process  synchronization  is  achieved  via  the  WAIT  primitive. 

A  process  which  needs  to  be  synchronized  with  another 
process  utilize  a  combination  of  the  Receive,  Set-Timer,  and 
Wait  primitives.  The  Receive  primitive  accepts  data  from  the 
mail  box  of  the  process  with  which  synchronization  is  desired. 
The  Set-Time  primitive  is  used  to  detect  a  synchronization 
failure  and  the  Wait  primitive  returns  to  the  calling  programs 
when  either  the  timer  elapses  or  the  expected  data  is  received 

The  above  scenario  may  lead  to  anyone  of  the  following 
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outcomes : 

1.  The  program  target  of  the  synchronization  request 
supplies  a  synchronization  message  and  the  WAIT 
primitive  returns  to  its  calling  program  thereby 
achieving  synchronization. 

2.  The  target  program  fails  to  supply  a  message  and  a 
count  down  timer  terminates  the  WAIT  primitive  which 
returns  an  error  message  to  its  calling  program. 

3. 1.5. 3. 5  Inter  Host  Communication 

Figure  3-46  shows  an  overview  of  the  Inter  Host 
Communication  Subsystem.  This  figure  illustrates  the  following 
concepts : 

1.  The  NTM  on  the  COMM  AP  Cluster  routes  all  inter  host 
traffic 

2.  A  COMM  Subsystem  is  dedicated  to  communication  with  a 
particular  host,  and  as  such  transmits  and  receives  on 
an  RS-232  port  dedicated  to  a  specific  host. 

3.  Each  COMM  Subsystem  uses  two  queues  to  communicate  with 
the  NTM  on  the  COMM  AP  Cluster.  One  queue  is  dedicated 
to  inbound  messages,  whereas  the  other  queue  is 
dedicated  to  outbound  messages. 

4.  The  COMM  Subsystems  invoke  a  count  down  timer  to  detect 
line  failures. 

5.  The  COMM  Subsystems  use  the  local  host  operating  system 
I/O  handler  to  control  their  respective  ports. 

6.  The  inbound  and  outbound  queues  can  contain  more  than 
one  message  at  a  time.  From  COMM  point-of-view ,  the 
queues  are  handled  on  a  FIFO  basis.  Any  scheduling  of 
the  messages  (both  in  and  outbound)  is  performed  by  the 
NTM  on  the  COMM  AP  Cluster.  COMM  is  responsible  for 
segmenting  messages  which  exceed  the  size  of  the 
communications  data  blocks.  The  COMM  is  also 
responsible  for  assembling  the  various  data  message 
segments  into  a  message  prior  to  routing  to  the  NTM. 
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3. 1.5. 3. 5.1  Message  Scheduling  (Future) 

(Initial  message  scheduling  is  on  a  FIFO  basis.) 

The  NTH  is  responsible  for  scheduling  the  messages  to  be 
transmitted  by  COMM .  The  scheduling  is  based  on  the  following 
rules: 

1.  The  messages  from  all  Application  Processes  on  an  AP 
Cluster  are  examined  for  the  highest  priority  on  a 
round  robin  basis. 

2.  Consecutive  messages  to  be  transmitted  to  COMM  do  not 
belong  to  the  sane  Application  Process  queue  unless  all 
other  queues  are  empty. 

3.  Messages  which  are  not  selected  (passed  over)  for 
transmission  because  of  insufficient  priority  are  aged 
to  ensure  that  they  are  not  indefinitely  delayed  in  a 
busy,  higher  priority  environment. 

4.  Back  pressure  is  applied,  if  necessary,  through  the 
round  robin  scheduling  by  skipping  those  queues  which 
cannot  be  transmitted  because  of  insufficient  space  on 
the  corresponding  queues.  This  implies  status  feedback 
from  the  receiving  AP  Cluster. 

Figure  3-47  supports  an  illustration  of  the  message 
priority  scheme  implementing  the  above  rules.  A  discussion  of 
the  message  scheduling  scenario  follows: 

Messages  issued  by  Application  Processes  API,  AP2 ,  and  AP3 , 
are  transmitted  via  mail  boxes  to  the  NTM.  These  messages  are 
queued  by  the  NTM.  The  queue  is  processed  according  to  the 
above  rules,  and  messages  selected  are  either  send  to  COMM  or  to 
another  NTM  on  the  same  host. 

The  messages  are  transmitted  to  the  COMM  AP  Cluster  NTM  via 
mory.  The  messages  are  segmented  into  message  segments  when 
required  and  queued  for  transmission  by  COMM. 

Upon  reception  by  COMM  (on  the  other  host),  the  message 
segments  are  reassembled  and  then  transmitted  to  the  COMM  AP 
Cluster  NTM.  The  messages  are  then  placed  in  the  mail  boxes  of 
the  Application  Processes.  When  a  mail  box  is  filled  to  the 
point  that  additional  messages  cannot  be  delivered,  back 
pressure  is  applied  to  the  sending  NTM  via  message  indicating 
the  mail  boxes  to  be  skipped  by  the  round  robbin  scheduler. 
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Figure  3-46.  Interhost  Communication  8  Overview 


This  message  is  sent  by  the  receiving  AP  Cluster  to  the 
transmitting  AP  Clusters. 

3. 1.5. 3. 5. 2  Transmission  Error  Detection 

To  improve  the  reliability  of  the  messages  received  by  the 
receiving  COMM  program  and  forward  to  the  NTM,  the  COMM  program 
performs  error  detection  and  provides  acknowledgement  (positive 
and  negative)  to  the  sending  COMM  program. 

3. 1.5. 3. 5. 3  Line  Protocol  Handling 

The  line  protocol  implemented  in  the  Test  Bed  establishes  a 
master  slave  relationship  between  the  sender  and  the  receiver. 
The  master  is  keeping  track  of  the  time  out  events  and  is 
responsible  for  terminating  the  transmission. 

It  must  be  noted  that  the  Honeywell  Level  6  and  IBM  3081 
computers  do  not  support  full  duplex  communication  through  their 
line  I/O  handlers. 

Figure  3-48  shows  the  line  protocol  contemplated  for  the 
Test  Bed,  and  supports  the  following  discussion. 
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Figure  3-47.  Message  Scheduling  (Interhost) 
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1 .  Idle  state 

The  OOMM  program  enters  the  Idle  state  when: 

a.  First  started 

b.  When  no  message  segment  was  received,  no  message 
segment  remains  to  be  transmitted  and  no  message  is 
queued  for  transmission 

2.  Make  line  bid 

The  OOMM  program  indioates  its  willingness  to  act  as  a 
master  by  sending  a  message  to  the  other  host.  If  the 
other  host  is  able  to  act  as  a  slave,  it  will 
acknowledge  the  request  by  sending  a  line  granted 
message . 

3.  Compute  9  wait  backoff  time 

If  the  other  host  was  in  the  process  of  bidding  for  the 
line,  a  backoff  time  is  oonputed  to  delay  by  a  fixed 
amount  of  time  the  retransmission  of  the  next  line  bid 
message.  In  the  Test  led.  only  two  OOMM  programs  may 
collide.  These  programs  are  configured  with  two 
markedly  different  backoff  time  constants.  This  simple 
scheme  ensures  that  the  second  line  bid  attempt  will 
not  collide.  It  also  implies  a  primary  or  favored  role 
for  one  of  the  two  COMM  programs  on  one  transmission 
1  ine  ■ 

4.  Time  Out 

A  fixed  time  out  timer  is  initiated  by  the  Master  after 
every  transmi ssion  Failure  for  the  slave  to  respond 
within  the  time  interval  causes  the  master  to 
retransmit.  After  a  fixed  number  of  retries,  the  line 
is  assumed  to  be  down  and  the  fault  is  reported  to  the 
NTH  This  tine  out  technique  applies  to  the  line 
bidding  as  well. 

5.  Get  first  message  segment  n 

The  OOMM  program  enters  this  state  when  a  line-granted 
Mssage  is  received  from  the  other  OOMM  program  The 
COMM  program  under  discussion  has  thus  gained  control 
of  the  line  and  is  ready  for  transmission  The  message 
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to  be  transmitted  is  assumed  to  be  K  message  segaent 
long,  with  the  first  segaent  to  be  transaitted  being 
nuaber  one. 

6.  Transait  aessage  segaent  n 

The  COMM  program  proceeds  with  the  transmission  of 
aessage  segaent  n.  The  COMM  program  appends  & 
trauasaission  header  and  trailer  to  the  data  block.  This 
header  contains  the  following  inforaation: 

•  Cyclic  tramsait  sequence  nuaber  (1,  2,  3)  which 
allows  the  detection  of  duplicate  and  aissed  blocks. 

•  Cyclic  receive  sequence  nuaber 

•  Control  byte  containing: 

-  Line  bid  indicator 

-  EOT  aarker 

-  Continued  aessage  flag 

-  ACK  or  MAX  aark  and  cyclic  trauasaission  indicator 
of  faulty  segaent 

-  Binary/native  flag 

The  trailer  contains  the  aessage  segaent  check  sub. 

Once  the  trauasaission  of  the  aessage  segaent  has 
been  coapleted,  the  COMM  program  waits  for  an 
acknovledgaent  froa  the  receiver. 

7.  Get  next  aessage  segaent  (n  -  2.N) 

A  positive  acknowledge  froa  the  receiver  indicates  that 
no  errors  were  detected  and  that  the  transaission  aay 
proceed  with  the  next  aessage  segaent. 

8.  Repeat  a  tiaes 

A  negative  acknowledge  froa  the  receiver  Indicates  that 
an  error  was  detected.  The  receiver  indicates  in  its 
negative  acknowledge  the  nuaber  of  the  aessage  segaent 
to  be  retransaitted.  The  retransaission  sequence  is 
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attempted  a  times  before  the  OOMM  program  assumes  that 
a  hard  failure  is  present  in  the  system. 

9 .  Send  EOT 

The  master  sends  a  message  containing  the  EOT  control 
flag  when  transmission  is  complete.  This  message  does 
not  contain  data,  and  is  used  by  the  reoeiver  to  detect 
the  end  of  the  transmission. 

10 .  Grant  1 ine 

When  the  COMM  program  is  in  the  Idle  state,  it  responds 
to  a  line  bid  from  its  partner  by  a  line  granted 
message  to  indicate  that  it  can  assume  the  role  of  the 
slave. 

11.  Receive  B  acknowledge  message  segments 

When  in  the  slave  node,  OOMM  proceeds  with  receiving 
and  checking  the  message  segments  sent  to  it.  OOMM 
provides  a  negative  acknowledge  when: 

e  The  NTH  input  mail  box  is  full 

•  The  message  segment  is  out  of  sequence 

•  The  message  checksum  is  in  error 

The  acknowledge  messages  may  be  accompanied  by  message 
segments  when  there  are  messages  to  be  transmitted  by 
the  slave  to  the  master.  The  slave  to  master 
transmission  proceeds  as  described  above.  A  slave  time 
out  is  required  to  detect  failures  in  the  master  or  in 
the  Local  Area  Network.  In  this  event,  the  slave 
returns  a  fatal  error  message  to  the  MTM. 

Configuration  B  Maintenance 

The  Configuration  of  the  Communication  Subsystem  includes: 

•  Port /Host  Assignment 

•  Port  Configuration 

•  Line  Back  Off  Time  Constraint  (primary,  secondary) 
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The  above  assignments  are  data  driven.  Thus 
reconfiguration  does  not  imply  recompilation.  Whenever 
feasible,  the  configuration  data  is  kept  in  the  CDM  and  is 
downloaded  at  startup  time.  This  approach  does  not  apply 
to  the  minimum  communication  capabilities  required  to  boot 
the  IISS  System.  The  configuration  data  for  the  minimum 
boot  system  is  however  data  driven,  and  is  contained  in 
tables  supported  by  the  looal  hosts. 

3. 1.5. 4  Communication  Subsystem  Functional  Specifications 

The  functional  specifications  implied  in  the  scenarios 
presented  in  Section  3. 1.5. 3  are  identified  and  presented  in 
this  Section. 

Local  Area  Me twork 


Mission:  To  interconnect  the  VAX,  Honeywell  cluster 
controller  via  Permanent  Virtual  Circuits. 

Functional  Specifications: 

e  A  minimum  of  3  permanent  Virtual  Circuits 

e  A  minimum  of  6  RS-232-C  configurable  port6 

•  Error  detection 

•  Hardware  diagnostics 

•  Configuration  data  is  stored  in  ROM  memory 
Wide  Area  Network 


Mission:  (1)  to  interconnect  the  IBM  3081  with  the  cluster 

controller,  and  (2)  to  multiplex  4  lines  to  the  VAX. 
Honeywell  Level  6  and  to  the  cluster  controller. 

Functional  Specifications 

1.  Cluster  Controller 

•  EBCDIC  to  ASCII  conversion 

•  Synchronous  to  Asynchronous  protocol  conversion 
e  Single  Line  4800  bauds  modem  to  support  leased 


3-136 


SDS620 140000 
1  November  1985 


telephone  line 

e  Protocol  compatibility  with  GE  and  Boeing  IBM  30xx 
computers 

e  A  minimum  of  7  RS-232-C  ports  to  be 

multiplexed/demultiplexed  into  the  synchronous  line 

2.  Line  Multiplexer 

e  Multiplex  switched  network  telephone  lines  into  the 
following  equipment: 

-  VAX  RS-232-C  port 

-  Honeywell  RS-232-C  port 

-  Cluster  Controller  RS-232-C  port 

-  CIDS  leased  telephone  line  (Initial) 

-  Provide  MODEM  capabilities  for  dialup  lines  (Bell 
103) 

-  Multiplex  local  terminals  into  the  above  listed 
equipment 

Inter  Process  Communication 


Mission:  To  provide  Communication  Services  supporting  on  host, 
process  to  process  communications  operations.  The 
primitives  support  setting  up.  operating,  tearing  down 
the  communication  resources  under  normal  and  abnormal 
termination  modes  and  error  processing. 

Functional  Specifications 

e  Generate  unique  mall  box  identifiers  for  communication 
between  a  given  instance  of  a  process  and  the  HTH. 

e  Create  the  input  and  output  mail  boxes  bearing 
identifiers  developed  above 

e  Communicate  identification  of  nai 1  boxes  to  the  VTM 

e  Write  into  mail  boxes 
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•  Read  from  mail  box  when  mail  box  has  been  written  into 

•  Notify  NTH  of  the  nature  of  the  errors  detected  by  the 
I PC  servioes 

e  Obtain  name  and  si me  of  buffer  where  data  is  to  be 
stored 

e  Detect  buffer  overrun 
e  Detect  reading  from  an  empty  buffer 
e  Clear  mail  boxes  when  terminating 
Interprocess  Communication 

Mission:  To  provide  Communication  Services  supporting  inter¬ 
host,  NTH  to  NTH  communication.  The  primitives 
support  setting  up,  operating,  tearing  down  the 
communication  resources  under  normal  and  abnormal 
termination  modes  and  error  processing. 

Functional  Specifications 

e  Maintain  inbound  and  outbound  message  queues 

e  Provide  FIFO  message  processing  with  sane  priority  level 

•  Detect  failures  in  bocal  Area  Network 

e  Provide  bidirectional  communications  between  any  two 
hosts 

•  Detect  transmission  errors  (incomplete  messages,  bit 
drop  out) 

•  Detect  message  duplication 

•  Support  master/slave  line  protocol  described  in 
3.1 .5.4.3 

e  Provide  message  segement  check  sum 
e  Append  transmission  header 
e  Append  message  end  flag 
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•  Provide  ACK/NACK  on  block  receive 

•  Retransmit  n  times  before  declaring  a  hard  failure. 

Number  of  retries  is  defined  with  configuration  data 

Configuration  g  Maintenance 

Mission:  (1)  to  configure  the  Communication  Subsystem  to  allow 
booting  the  I1SS  software,  (2)  to  download  the 
configuration  data  not  required  for  booting,  and  (S) 
to  maintain  the  configuration  data. 


Functional  Specifications 


•  Create  and  maintain  local  tables  containing  minimum 
configuration  data  for  booting 

•  Download  CDM  supported  configuration  data  upon  request 
from  the  hosts 

•  Create  and  maintain  the  CDM  supported  configuration 
data  tables 

3.2  Interfaces 

This  section  describes  the  system-level  interfaces  between 
the  principal  IISS  Test  Bed  software  subsystems.  An  overview  of 
the  Test  Bed  is  shown  in  Figure  3-49.  The  major  software 
components  identified  in  this  figure  are: 

•  Integrated  Application  Programs  (AP's) 

•  Non-Integrated  Application  Programs  (MCMM,  MRP) 

•  Common  Data  Model  (CDM) 

•  Distributed  Database  System  (DDBS)  Processes 

•  Local  Database  Management  Systems  (DBMS) 

•  Network  Transaction  Manager  (NTM) 

•  User  Interface  (UI) 


•  Communication  Subsystem  (COMM) 

•  Test  Bed  Monitor 
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The  obvious  interfaces  are  the  lines  drawn  between 
components  in  Figure  3-49.  However,  there  are  several  levels, 
or  “layers",  of  interfaces  and  there  are  also  "protocols" 
between  components  that  are  not  shown  in  this  figure.  For 
example,  three  important  components  not  shown  in  the  figure  are: 

•  Interprocess  Communications  Subsystem  (IPC) 

•  Virtual  Terminal  Interface  (VTI) 

•  Host  Operating  Systems 

The  following  subsections  describe  the  system-level 
information  interfaces,  the  services  to  be  provided,  and  the 
protocols  to  be  established  between  software  subsystems  in  the 
IISS  Test  Bed.  Additional  detail  on  interfaces  can  be  found  in 
the  individual  Configuration  Item  Development  Specifications 
(DS's)  and  Product  Specifications  (PS's)  to  be  developed  for 
each  software  subsystem. 

3.2.1  Information  Interfaces 


This  section  describes  more  detail  about  the  kinds  of 
information  exchanged  between  software  subsystems.  Since 
information  could  potentially  be  exchanged  between  any  pair  of 
software  components,  a  matrix  is  used  to  show  all  of  the 
possible  connections.  A  matrix  showing  the  12  categories  of 
software  components  identified  above  is  presented  in  Figure 
3-50.  The  software  components  are  listed  along  the  diagonal. 

Each  row  indicates  that  output  and  the  corresponding  column 
indicates  the  input  it  may  receive.  Hence,  information  flows 
clockwise.  For  example,  an  Integrated  Application  Process  (row 
1)  may  send  query  requests  to  Distributed  Database  Processes 
(column  4)  and  will  receive  files  of  requested  data  in  return 
(row  4,  column  1).  Where  no  interface  exists  between  a  pair  of 
software  components,  large  X's  are  placed  in  the  corresponding 
boxes . 

Figure  3-50  shows  how  each  of  the  software  components  fit 
into  a  system  framework.  Components  with  many  interconnections 
such  as  the  NTH  are  clearly  shown  to  be  critical  elements  in  the 
system.  Other  components  such  as  the  User  Interface,  Local 
DBMS  s ,  and  Telecommunications  are  shown  to  be  relatively 
independent  subsystems . 
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3.2.2  Services  Provided  (Internal  Interfaces) 

This  section  presents  the  IISS  system  interface 
requirements  by  describing  the  services  to  be  provided  by  each 
of  the  major  software  components.  The  services  provided  by  a 
software  component  are  typically  a  subset  of  the  functions  it 
must  perform.  These  are  the  functions  it  will  be  called  upon 
directly  by  other  software  components  to  perform.  For  example, 
the  NTH  will  be  called  upon  to  send  messages  between  applicatin 
processes.  This  is  a  service.  The  NTH  must  also  validate 
message  header  information  and  route  messages  to  their 
destinations,  but  these  are  not  considered  services  in  this 
context . 

3.2.2. 1  Integrated  Application  Programs 

Integrated  application  programs  provide  "external “  services 
to  IISS  users  and  may  cooperate  with  other  Test  Bed  programs. 
However,  application  programs  are  not  considered  to  serve  in  any 
subordinate  role  with  respect  to  other  Test  Bed  software. 

Hence,  no  "internal"  services  are  associated  with  application 
programs . 

The  service  interfaces  supported  by  other  Test  Bed  software 
components  and  used  directly  by  application  programs  are 
summarized  in  Figure  3-51.  This  figure  shows  the  structure  of  a 
typical  application  program  as  consisting  of  COBOL  source  code 
and  several  layers  of  service  routines  which  will  be  provided 
from  Test  Bed  software  libraries.  The  first-level  interfaces 
connect  the  application  program  with  the  User  Interface, 
Distributed  Database  Processes  (through  precompiled  Neutral  Data 
Manipulation  Language  ( NDML )  statements),  and  the  Network 
Transaction  Manager.  The  lower -level  interfaces  show  the 
connections  with  Interprocess  Communications  and  the  host 
operating  system.  Hence,  Figure  3-51  reiterates  the  interfaces 
described  by  the  top  row  and  first  column  of  the  N-squared 
matrix  shown  in  Figure  3-50. 

3. 2. 2. 2  Non-Integrated  Application  Processes 

Non-Integrated  application  programs  neither  provide  nor  use 
Test  Bed  related  services. 

3. 2. 2. 3  Common  Data  Model 

The  CDM  has  two  principal  roles  in  the  Test  Bed 
environment.  One  is  maintaining  an  accurate  picture  of  the  data 
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stored  throughout  the  Test  Bed  computer  network.  The  other  is 
naking  this  information  available  to  Test  Bed  system  and  user 
processes.  Maintenance  of  the  CDM  database  is  the 
responsibility  of  the  CDM  database  administrator  and  is  not 
considered  a  service.  Providing  data  to  Test  Bed  processes, 
however,  is  a  service.  The  mechanism  for  calling  upon  CDM 
services  is  through  MDML  statements.  Translation  of  KDML 
statements  is  a  CDM  function,  but  it  is  not  considered  a 
service.  The  requirements  for  the  NDKL  syntax  are  shown  in  the 
CDM  Processor  Development  Specifications.  The  syntax  of  MDKL 
statements  and  the  techniques  for  embedding  queries  in  COBOL  and 
Fortran  programs  fora  the  CDM  interface,  and  are  fully  described 
in  the  NDML  Precompiler  Development  Specifications. 

3. 2. 2. 4  Distributed  Dat»>*»se  Processes 

Figure  3-52  depicts  the  configuration  of  processes  required 
to  perform  a  query  for  distributed  data.  All  of  these  processes 
(except  the  application  process  initiating  the  request)  are 
"owned"  by  the  CDM  and  only  provide  services  for  query 
processing.  However,  distributed  queries  are  the  most  ooaplex 
scenarios  of  communicating  processes  considered  for  the  Test  Bed 
environment,  and  they  have  "driven"  the  requirements  for  the 
NTM  Hence,  the  top  layer  of  CDM  internals  has  been  exposed  at 
the  system  level .  The  servioes  provided  by  each  of  the 
components  shown  in  Figure  3-52  are  outlined  below: 

•  Distributed  Request  Supervisor  (Stager  Scheduler) 

•  Local  Request  Processors 

•  Data  Aggregators 

•  Conceptual  to  External  Schema  Transformer 

3. 2. 2. 5  Local  Database  Management  Systems 

Each  local  DBMS  represents  a  unique  interface  for  the  local 
database  request  processes  discussed  above.  These  Interfaces 
and  the  services  a  DBMS  must  provide  for  query  execution  shall 
be  addressed  in  the  HDML  Precompiler  and  Local  Request  Process 
Generator  design  documentation. 

3. 2. 2. 6  network  Transaction  Manager 

Application  Processes.  Distributed  Database  Processes 
(DDP's),  the  User  Interface,  and  other  Test  Bed  programs  will 
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call  upon  Ut  8TM  for  4  Mjor  categories  of  servloes: 

•  Prootn  Logon  ud  Logoff 
o  Initiating  ud  Toro  loot  log  Processes 

o  Bending  ud  Receiving  Messages 

o  Obtaining  States  of  Nmm|m  aad  ProoMm 

Bock  of  these  categor les  is  ewpsnded  lo  following 
paragraphs 


The  aooluaiM  for  invoking  these  servloes  Is  through  a 
library  of  servioe  root  loot  which  Is  lo  bo  linked  lolo  each 
call  log  prograa  ( soo  Figaro  8-81).  This  IsofealfM  allows  ibo  VTH 
lo  view  AFs .  database  processes,  aad  the  01  as  siaply 
'processes  '  It  also  allows  the  0TN  lo  of foci 1 rely  hide  the 
dotal  1b  of  0TM  oos sage  headers .packet  sloe,  aad  the  I PC 
lolorfaoe  f roe  8TH  users  The  VTH  oast  therefore  provide  the 
folloviog  servloes 

88  3.6.1  Prooess  Lodoo  aad  Logoff 

1  Enable  prograas  initiated  aader  local  operating  systens 
to  establish  connections  to  the  I IBS  Tost  Bed 

32262  Prooess  Initiation  and  Toro I nail on 

1  Enable  authorised  processes  to  Initiate  other 
processes  Initiated  processes  nay  reside  in  the  sane 
application  cluster,  in  different  application  clusters 
on  the  sasw  host,  or  in  application  clusters  on  other 
hosts 

2  Enable  delayed  process  initiation  The  delay  nay  be 
until  a  specified  tine  in  the  future  or  for  a  specified 
elapsed  tine  fron  the  tine  of  the  re<fuest . 

3  Enable  initiation  of  aultiple  instances  of  a  process 
w i thout  having  to  wait  for  one  instance  to  conplete 
before  initiating  the  next. 

4  Enable  an  authorised  process  to  abort  another  process. 

5  Enable  a  process  to  wait  until  another  process  or 
application  cluster  becones  available. 
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S. 2. 2-6.3  Sud  and  Receive  Messages 

1.  Enable  a  process  to  send  &  message  over  a  logical 
channel  to  another  process.  Messages  nay  require  a 
response  (i.e..  paired  messages  and  guaranteed-de livery 
messages).  Messages  may  also  be  either  binary  data 
which  is  to  be  received  exactly  as  sent,  or  text  which 
may  require  character  code  conversion  when  transmitted 
between  hosts . 

2.  Enable  a  process  to  receive  a  message  from  a  specified 
logical  channel . 

3.  Enable  a  process  to  receive  the  next  message  arriving 
on  any  ohannel . 

4.  Enable  a  process  to  wait  until  a  message  arrives 
(Reoeive  with  a  wait). 

5.  Enable  a  process -to  check  for  the  presenoe  of  an 
incoming  message  (with  or  without  actually  obtaining 
the  message)  either  from  a  specific  ohannel  or  from  any 
ohannel . 

6.  Enable  a  process  to  acknowledge  the  successful 
completion  of  processing  in  response  to  a 
guaranteed-de 1 i very  message . 

7.  Enable  a  process  to  indicate  that  it  is  under  te6t  and 
that  its  messages  should  not  be  allowed  to  corrupt 
normal  system  operation.  (Future  -  Test  mode  indicator 
can  be  set/reset,  but  interpretation  is  AP  specific). 

3. 2. 2. 6. 4  Obtain  Status  of  Messages  and  Processes 

1.  Enable  an  authorized  process  to  obtain  the  logical 
names  of  the  host  and  application  cluster  in  which 
other  processes  reside,  as  well  as  the  names  of  its  own 
host  and  application  cluster. 

2.  Enable  an  authorized  process  to  obtain  the  status  of 
hosts,  application  clusters,  and  processes. 

3.  Enable  a  process  to  obtain  all  necessary  information 
(e.g.,  user's  identification,  the  User  Interface 
process  name,  and  a  suitable  logical  channel)  to  send 
informative  messages  to  the  user  whose  initial  request 
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caused  its  execution. 


4.  Enable  a  process  to  check  the  status  of  any 

guar an teed -deli very  Messages  it  has  issued.  (Future) 

5.  Enable  a  process  to  check  the  status  of  any  Messages 
for  which  replies  are  expected.  (Future) 

S.2.2.7  User  Interface 

The  User  Interface  provides  a  number  of  servioes  to  IISS 
users  such  as  sinple  Menu-driven  control  of  prograns  and  a 
convenient  "help"  function.  However,  the  interface  described  in 
thi6  section  focuses  on  the  servioes  provided  by  the  UX  to  other 
Test  Bed  software  ooaponents  —  principally  Application 
Prograns.  The  UI  Must  provide  the  following  services  to  oontrol 
the  display  of  fores  and  data,  and  retrieve  user  input: 


1 . 


2. 


S. 


4. 


6. 

3. 2. 2. 8 


Select  fores  to  the  displayed  fron  a  collection  of 
previously  defined,  stored  forns 

Insert  data  into  fields  before  they  are  displayed 

Display  part  or  all  of  a  fora  on  the  user's  screen 

Allow  field  values  to  be  updated  on  the  screen 

Erase  part  or  all  of  a  display 

Accept  data  from  the  user ' s  keyboard 

Commun i cat i ons 


The  principal  role  of  the  Coaauni cat ions  Subsystem  is  to 
provide  host-to-host  message  (packet  transfer).  The  Test  Bed 
software  architecture  has  allocated  two  COMM  processes  (one  at 
either  end)  for  each  pair  of  communicating  machines,  as  shown  in 
Figure  3-49.  Hence,  messages  sent  via  a  given  COMM  process  go  to 
only  a  single  destination.  The  only  routing  and  distribution 
function  performed  by  COMM  processes  is  in  handling  high-  and 
low-priority  messages  which  are  sent  and  received  on  different 
IPC  channels  but  are  transritted  between  machines  over  a  common 
communications  channel  (Message  priority  -  Future).  The 
services  provided  by  COMM,  therefore,  are: 

1.  Transmission  of  messages  received  from  its  associated 
NTM  process  to  its  COMM  counterpart  on  another  host 
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2.  Forwarding  of  reoeivad  froa  lit  oorr— poad 1 ag 

COMM  process  to  Its  uiooitlad  MTN  prooaas 

3. 2. 2. 9  Test  Bad  Moat  lor 

o  Perforaaaoe  eon i tor inf 

o  loBTMOvtrftblt  failure  handling 


5.2.2.10 


Tho  objectives  of  the  Xaterprooess  Co— aaioatioaa 
Priaitives  (IPCs)  are  to  provide  a  aachiae- independent .  OOBOL 
intorfaoo  for  ooaaaaloatioa  between  cooperating  ooaoarroat 
processes.  In  the  IIES  Tost  Bad  eaviroaaeet.  appl loatioa 
profraas  will  ba  provldad  higher- level  aes sage -pass lag  servioes 
by  tho  MTU .  I PC  aarvioas  ara  expected  to  ba  aaad.  diraotly. 

only  by  Taat  Bad  *  ays tea*  aoftwara  aaoh  aa  tha  MTN  aad  COMM. 

Tha  aarvioas  tha  I PC  Priaitivaa  aaat  provida  for  tbaaa 
aubayataaa  ara  tha  following: 

1.  Katabliah  ooaaualoation  ohaaaala  batwaan  prooaaaaa 

2.  Sand  Mssagas  ovar  aatabliahad  coaeun i oat i on  ohaaaala 

3.  Raoalva  aaaaafaa  ovar  aatabliahad  ooaaunioat ion 
ohannals . 


4.  Suapand  a  calling  prooaaa  for  a  spacifiad  pariod  of 
tiaa  or  until  an  inooainf  aaaaafa  arrivaa. 

[Mota:  "Coaaunioation  channel*'  ara  iaplaaantad  by  a 
"Mai lbox*  oonoapt . ] 

3.2.2.11  Virtual  Teralnal  Intarfaca 

The  function  of  the  Virtual  Tamlnal  Intarfaoa  CVT1)  ia  to 
insulate  application  profraas  and  other  Test  Bad  software  froa 
the  special  characteristics  of  individual  display  teralnals. 
Each  brand  of  conputer  tarainal  uses  a  different  sat  of  oontrol 
characters  and  different  control  sequences  to  clear  tha  screen, 
position  the  cursor,  highlight  text,  scroll  displayed 
inforaation.  etc.  The  service  provided  by  the  VTI  is  the 
conversion  of  standard  control  characters  and  control  sequences 
as  needed  to  support  the  teralnals  connected  to  Test  Bad 
coaputars .  The  standard  internal  character  set  and  control 
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1  »o 


i  i  <  t 


ifwoi  will  Im  described 
Specif loftlloft 


s  a  a  n  jgfi  0— rfti  m  »tiVm« 

■oat  oporatlag  ays Vmm  pr«vl4t  Mm  r«a -lift*  MViroaMat  for 
oil  of  ika  software  oMfMMii  described  atari  loft  a  of  Mm 

specific  rwa-ttfto  aorv toe*  itof  prarlla  include 

l  By a too  o*l la  for  laterpreooas  ooaftftftlooiloft 

1  lyaioft  o*l la  for  preoess  tftllloilo*  **d  tors l**i loo 

S  1/0  prioitlves  for  iapat  Oft*  output  io  asor  ioraloola. 
Mm  loool  *ro*  outwork .  aad  altar  poriptor»la 


s  a  s  tttimii  yf  nti  t  till 

TIm  aorv 1 ooa  described  atari  *ro  iftoleftoated  la  * 
distributor  proooaa lag  ftftvlrooooftt  like  Mm  IIM  by  oaet*a|lft| 
'bos safes*  botvoo*  programs  Vbo*  too  profrooa  of  prooesaes 
cooperate  to  deliver  aorriooa.  tboy  ft* at  establ l at  *  aot  of 
rules  Mad  agreed -upoa  sassages  oblob.  tofotbor .  aro  oallod  * 
‘protocol*  Tbo  sassage  dlstribotlo*  aorv l ooa  sapportod  by  tbo 
BTB  IPC.  aad  00—1  aftbftystooft  provide  *  baa  1  a  for  lap I aft on ting 
thoao  protocol  a 

Tbo  ooftploxity  of  Toot  Bod  proooaa  lfttorooaftoctloaa  causes 
ooafusion  about  tbo  dtatiactloa  botwoon  lfttorfaooa  aad 
protocols  Figure  3-93  about  too  vtawt  of  proooaa  interaction 
On  tbo  loft  la  shown  a  ‘ftacro- lovol *  viov  of  a  protocol  botwoon 
two  application  procoaaoa  This  protoool  la  I  ftp!  won  tod  by 
intorfaoos  with  tbo  BTH  A  aiftilar  protoool  oaiata  between  tbo 
■TO  procoaaoa  aad.  at  tbo  bottoa  lovol.  a  tolocoaeunlcat loaa 
protocol  iftploftonta  tbo  actual  tranafor  of  tbo  data  On  tbo 
nfbt-hand  a  Ido  of  Fifuro  3-53  la  ah  own  a  ‘alcrosoopic*  v  low  of 
tho  intorfaco  botwoon  tbo  application  and  JTTH  procoaaoa  at  tbo 
loft  This  vlow  depicts  a  protocol  botwoon  that  application 
process  aad  tbo  *TM  that  is  lapleaented  by  intorfaooa  with  tbo 
I PC  Tbo  1188  Tost  Bod  aacro-lovol  protocols  aro  described  in 
tbo  following  paragraphs 

3.23.1  AP  to  AP 


Protocols  and  aossagos  exchanged  between  cooperating 
Appl  icatlon  Programs  (eg.,  in  a  distributed  AP)  oust  be  defined 
by  the  application  designers  This  information  could  ultimately 
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rtiidt  in  the  GSM  io  allot#  the  VTM  to  validate  the  exchange  of 
•hi«|m  at  rw-tiM 

a.a.a  a  ap  io  cow 

Tht  protocol  bolt#—  an  Appl  ioatioa  Prof  ran  aad  the  CDK  i 
dintribotod  database  prooossos  Is  oaboddod  aad  effectively 
hidden  witbin  tbo  RML  Tbls  allows  an  Appl  Ioatioa  Profraa  to 
ooaplotoly  avoid  direct  dealings  eitb  tbo  aes safes  eve banged 
between  it  aad  tbo  GDM  processes.  Tbo  ooateat  aad  foraat  of 
these  nos sages  are  defined  by  tbo  GDM  Preooapiler 

a. a  a. 3  ap  to  m< 

Tbo  protoool  between  Appl ioatioa  Prograas  aad  tbo  VTM  is 
oaboddod  vitbin  tbo  library  of  VTM  service  routines  wbiob  aust 
be  linked  into  every  Test  Bed  profraa.  This  ainiaises  the 
dependencies  on  VTM  nos safe  character isti os  snob  as  bender 
inforaatioa  aad  no s safe  (paoket)  leafth  within  profraas  The 
ooateat  aad  foraat  of  the  VTM  ‘nos safe  envelope*  are  defined  by 
the  VTM 

a  a  a.4  ap  to  oi 

The  protoool  between  Application  Profraas  aad  tbo  User 
Interface  are  oaboddod  within  tbo  library  of  01  servioe  routines 
to  ainiaiso  dependencies  on  tbo  types  of  ness ages  exchanged  with 
the  01  The  fora  aad  content  of  these  aossafos  are  defined  by 
the  01 

a. a. a  a  com  to  com 

Messages  exchanged  between  distributed  database  processes, 
including  local  database  request  processes,  are  defined  by  the 
CDM  Further  detail  on  these  aessages  will  be  presented  in  the 
COM  Developaent  Specification 

3  3.3.6  VTM  to  VTM 

Messages  exchanged  between  VTM  processes,  either  to  forward 
aessages  between  Application  Process  Clusters  or  for  VTM  process 
aanageaent .  are  defined  by  the  VTM  Further  detail  on  these 
aessages  will  be  presented  in  the  VTM  Developaent  Specification 
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SECTION  4 

QUALITY  ASSURANCE  PROVISIONS 


Requirements  for  formal  tests /verifications  of  the  IISS 
system  design  characteristics  and  operability  will  be  specified 
based  on  the  hardware  used,  combinations  of  developed  softwre. 
as  well  as  the  developed  implementation  schedule.  Vhile  a 
detailed  Quality  Assuranoe  Plan  cannot  be  developed  at  this 
time,  oritioal  minimum  requirements  have  been  identified. 

4.1  General 

A  simplified  breakdown  of  a  system  build  and  validation 
against  functionality  requirements  would  include  the  following 
major  activities: 

e  Develop  and  Verify  Program  Modules 
e  Develop  and  Verify  Programs 

e  Develop  and  Verify  Subsystem  Nodules 

e  Develop  and  Verify  Subsystems 

e  Develop  and  Verify  System 

e  Volume  Test  System 

Testing/val idating  will  be  performed  as  required  as  part  of  each 
of  these  activities.  The  testing  procedures  will  be  designed  to 
validate  that  the  functionality  developed  in  the  design  has  been 
fulfilled. 

4.1.1  Responsibility  for  Test 

Test/val idation  responsibility  will  be  divided  based  on  the 
contractor  or  subcontractor  involved  in  the  program  module, 
program,  and  subsystem  module. 

Responsibility  for  testing/val idating  subsystems  and 
systems  will  fall  to  the  involved  contractor  and  the  user. 

4 . 2  Special  Tests  and  Examinations 

Whenever  software  has  been  purchased,  the  vendor  shall  be 
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responsible  for  insuring  that  the  paok&ge  will  natoh  the 
functional  specifications  previously  developed  and  provided  to 
the  vendor.  (It  is  expected  that  vendors  will  be  responsible 
for  insuring  the  packages  perforn  whatever  functions  are 
neoessary  to  support  the  functionality  requested.) 
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SECTION  5 

PREPARATION  FOR  DELIVERY 


5 . 1  Hardware 


The  Test  Bed  hardware  owned  by  the  Air  Force  is  60heduled 
to  be  delivered  to  the  Air  Foproe  when  it  is  no  longer  required 
to  support  the  TestBed  programmatic  activities.  The  hardware 
shall  be  delivered  in  accordance  with  Air  Foroe  instructions, 
schedule,  and  at  Air  Force  expense. 

5.2  Software 

The  software  developed  under  Project  6201H  shall  be 
delivered  to  the  I CAN  program  office  in  accordance  with  the  Test 
Bed  Configuration  Management  Plan.  The  Software  Configuration 
Management  Plan  for  is  published  in  the  Final  Technical  Report 
Volume  I  ( FTR620 100001 )  and  in  the  documents  for  the  Software 
Configuration  Management  (SCM)  system  listed  in  the  Appendix  of 
the  final  report. 

5 . 3  Documents,  t  i  on 


The  following  Users  Manuals  have  been  prepared  under 
Project  6201M  and  will  be  delivered  to  the  I CAM  program  office 
in  accordance  with  the  Test  Bed  Configuration  Management  Plan. 
See  the  Final  Technical  Report  Volume  1  (FTR620100001 )  for  a 
complete  list  of  all  documents  delivered  under  this  contract. 

5.3.1  HTM  Programmer's  Manual  (Services) 

This  manual  describes  the  services  provided  to  IISS 
programmers  by  the  Network  Transaction  Manager.  These  services 
are  used  by  IISS  Application  Programs  to  send  messages  to  and 
receive  messages  from  other  programs  in  IISS.  This  document  is 
useful  to  programmers  who  are  building  IISS  component  programs 
and  need  to  embed  currently  available  NTH  service  calls  in  their 
programs.  The  document  includes  notes  on  restrictions,  helpful 
hints,  and  reports  on  experience  gained  on  the  NTH. 

5.3.2  NTM  Operator' s  Manual 

The  NTH  Operator ' s  Manual  describes  the  procedures  and 
message  exchanges  taking  place  during  the  various  phases  of  the 
NTM  operational  life  cycle.  Operator  commands,  IISS  error 
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codes.  NTH  table  — intenanoe  procedures,  and  BTB  troubleshooting 
procedures  are  also  given. 

5.3.3.  Co— on  Data  Model  (CDM)  Administrator  s  Manual 

The  primary  focus  of  the  CO  Administrator  s  Manual  is 
placed  upon  the  Scheae  Intergration  Methodology  which  is 
intended  to  guide  a  CO  administrator  in  building  and 
maintaining  the  CO  database.  Pour  —dels  are  provided  as 
oouponents  of  the  — thodology  Two  of  the  models  are  I0SP0 
models.  These  models  address  building  the  initial  conceptual 
schema  and  its  incremental  expansion  The  CO  Administrator  s 
Manual  reflects  the  experience  gained  in  integrating  the  BMP  and 
HC-KM  subsystems 

5.3.4  Precompiler  Users  Guide 

The  Precomp 1 ler  User ' s  Guide  describes  the  procedures  to  be 
followed  to  preooapi le  the  MOL  statements  embedded  in  a  COBOL 
source  program.  This  manual  describes  the  functions  to  be 
invoked,  the  naming  conventions  of  the  intermediate  files,  and 
the  commands  to  be  executed  to  review  the  source  listing  and  the 
listing  of  the  code  generated  by  the  Precompiler 

5.3.5  MDHL  Dsers  Manual 

This  manual  describes  the  requirements,  theoretical 
foundation,  commands  and  syntax  of  the  XISS  Neutral  Data 
Manupulation  Language.  The  Commands  section  of  the  manual 
consists  of  syntax  and  examples  of  the  stand-alone  BDML 
statements.  Each  NDML  clause  is  described.  The  Embedded  BDML 
section  describes  the  use  of  loopin.  constructs  containing  BDML 
statements,  and  states  restrictions  on  the  use  of  looping 
constructs  containing  BDML  state— nts  with  in  a  COBOL  prograa 
The  BBF  ( Backus -Baur  Form)  includes  a  for— 1  BBF  description  of 
the  stand-alone  form  of  the  BDML. 

5.3.6  PIMS  User  s  Manual 


The  User  Interface  Management  System  Services  ( UIMS )  Manual 
describes  the  forms  and  services  availabe  to  the  IISS  user  In 
particular,  the  nanual  describes  how  to  choose  a  function,  to 
change  password,  to  define  an  application,  to  define  a  command, 
to  update  a  command,  to  define  command  parameters,  and  to 
execute  an  application.  The  manual  contains  examples  and  error 
messages . 
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5.3.7  VTI  Programmer's  Manual 

The  Virtual  Terminal  Interface  (BTI )  Progr«»er * s  Manual 
describes  how  to  add  a  new  terminal  type  to  the  Virtual  Terainal 
Interfaces.  The  manual  describes,  in  detail,  the  four  files 
asking  up  the  VTI  terainal  type  definition.  These  files  are: 
the  Definition  File,  the  Lexical  Analyser  Table,  the  Parser 
Table,  and  a  Command  Generation  Table.  The  naming  convention 
for  each  file  is  also  given. 

5.3.8  Forms  Processor  Application  Programmer  Manual 

This  document  describes  the  callable  interface  to  the  Form 
Processor  and  is  intended  for  the  IISS  application  Programmers. 
The  Form  Processor  routines  use  predefined  forms  to  give 
programs  the  ability  to  read  input  and  write  data  to  terminals. 
The  manual  describes  in  detail  each  of  the  services  provided  and 
callable  routines. 

5.3.9  Interim  Forms  Editor  Manual 


The  Interim  Forms  Editor  is  based  on  a  Digital  Equipment 
Corporation  IMS  Forms  Editor.  The  Interim  Forms  Editor  Manual 
describes  the  data  required  to  define  a  form  and  the 
restrictions  bearing  on  the  fora  definition  process. 

5.3.10  MDDL  Users  Guide 

The  MDDL  Pser ' s  Guide  describes  the  syntax  and  semantics  of 
each  MDDL  command.  It  describes  how  to  use  the  language.  It 
does  not  describe  the  role  of  maintaining  the  CDM  which  is  found 
in  the  CDM  Administrator's  Manual. 


